Re: [go-nuts] Error handling

I think the proposal goes beyond saving few keystrokes.. as demonstrated in several of my replies above. The issue is readability and avoiding creating new scope with the current shortcut approach if x, err:=fn(); err!=nil. On Wednesday, August 2, 2023 at 2:58:42 PM UTC-6 Wojciech S. Czarnecki

Re: [go-nuts] Error handling

Fully agree.. I think my proposal is targeted primarily at that group although recognizing the strength and ability of group #1 to block any discussion On Wednesday, August 2, 2023 at 1:30:00 PM UTC-6 TheDiveO wrote: > Sorry to f'up on myself, but I would like to add regarding #1: at least my

Re: [go-nuts] Error handling

Great point! Gophers like any human tribes can become victims of absolutest thinking. In the gophers' case, tenets like "there should be only way of doing things" while admirable and justified most of the time can inhibit discussions about possible improvements. There are times where it is

Re: [go-nuts] Error handling

Dnia 2023-07-29, o godz. 22:57:15 DrGo napisał(a): > This involves introducing a new keyword "orelse" that is a syntactic sugar > for an "if err!=nil" block. You can implement it as a snippet under any editor in use today. If your goal is to personally have it in just one line, you can turn

Re: [go-nuts] Error handling

Sorry to f'up on myself, but I would like to add regarding #1: at least my personal impression is that for #1 it looks very difficult to improve this in any meaningful way. It looks to me as if #2 is actually where the improvements would bear large fruit as it makes Go more welcoming and

Re: [go-nuts] Error handling

Ben Hoyt's blog post Scripting with Go: a 400-line Git client that... mentions error handling from a perspective that made me clear for the first time why I'm always in two minds when it comes to Go's error handling: 1. the perspective of a prod-code

Re: [go-nuts] Error handling

Fair enough … I understand that people have different styles On Wednesday, August 2, 2023 at 12:54:20 AM UTC-6 Brian Candler wrote: > FWIW, I'm in the "I like how it is now better than any other proposal so > far" camp; I think this happens as you get used to the Go way. Go is Go. > > The only

Re: [go-nuts] Error handling

FWIW, I'm in the "I like how it is now better than any other proposal so far" camp; I think this happens as you get used to the Go way. Go is Go. The only thing I would consider is making *interface* types (only) implicitly usable in a boolean context, e.g. if err { ... } However, I suppose

Re: [go-nuts] Error handling

Yeah.. I mean, the "idiom" `err != nil return` err is something of the language. I complain about the boilerplate that idiom produces and that is fact fact (no one can deny it). You know, your approach implies making the language a little more complicated as new ways to deal with errors appear. I

Re: [go-nuts] Error handling

On Tue, Aug 1, 2023 at 10:18 AM DrGo wrote: > >> What happens if all of a sudden, the makeSomeNoise returns 2 errors? Then > you have to undo the orelse construction, for what I understand. > No as long as both errors are meant to be handled as errors. Orelse will > be triggered if any or both

Re: [go-nuts] Error handling

And of course I forgot the "if" at the beginning of all those conditional. *sigh* -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [go-nuts] Error handling

>> What happens if all of a sudden, the makeSomeNoise returns 2 errors? Then you have to undo the orelse construction, for what I understand. No as long as both errors are meant to be handled as errors. Orelse will be triggered if any or both were not nil. On Tuesday, August 1, 2023 at 1:36:04 

Re: [go-nuts] Error handling

If I look at the following example: ``` err := io.Copy(w, r) *orelse* { DoSomethingElse() } ``` This can be written usually as: ``` if io.Copy(w, r) != nil { DoSomethingElse() } ``` which is LESS boilerplate. So only for the case when there is multiple return values, there is some savings in

Re: [go-nuts] Error handling

For some perspective. Go’s error handling mimics C (for the most part). They had a decade to decide how to improve the error handling when they designed C++. They came up with exceptions. Java is C++ like. They had a decade to improve error handling. They came up with exceptions + throws. The

[go-nuts] Error handling

I looked at the long list of proposals to improve error handling in go but I have not seen the one I am describing below. If I missed a similar , can you pls direct me to where I can find it. If not what do you think of this approach. This involves introducing a new keyword "orelse" that is a

Re: [go-nuts] error handling thoughts

On Thu, Jul 27, 2023 at 8:04 AM Steve Roth wrote: > > In those cases, what I'd like to write is > > if result, err := fn(); err != nil { > > // handle error and bail out > > } else { > > // act on result > } > > > Unfortunately, the compiler gives a warning on that. As others have

[go-nuts] error handling thoughts

The ongoing Go survey asked a question about satisfaction with error handling in Go. I'd like to express an opinion on it that I haven't seen elsewhere, for which there was not room in the survey. I am generally a fan of the explicit error handling code in Go, but I get frustrated by the

Re: [go-nuts] Error Handling

I agree with Axel that a function like errReturn is a bad idea, though if Go updates/improves error handling, it's possible we'll get something like that (some of the error handling proposals have been similar to errReturn). However, I don't see anything wrong with a function like Richard's

Re: [go-nuts] Error Handling

You said: "and FTR, I'd also consider your function a bad idea, but that's none of my business" <- I'll be the first to say not all my ideas are good ones, maybe this one isn't? Thanks for your response. On Tue, Feb 7, 2023 at 4:45 PM Axel Wagner wrote: > No, that is not possible. Only a

Re: [go-nuts] Error Handling

No, that is not possible. Only a `return` statement can return. You *can* unwind the stack, using `panic` or `runtime.GoExit` (which is what `t.Fatal` does) but it's a bad idea in general (and FTR, I'd also consider your function a bad idea, but that's none of my business). On Tue, Feb 7, 2023 at

[go-nuts] Error Handling

In most of my code I create a function to handle errors. looks something like this: func errorHandle(err error, str string, ex bool) { if err != nil { fmt.Printf("error: %s -- %v\n",str, err) } if ex { os.Exit(1) } } This cleans up my code: inFile, err

Re: [go-nuts] Error Handling Question

On Oct 25, 2022, at 2:28 PM, 'Daniel Lepage' via golang-nuts wrote: > > In contrast, the modern Go version buries the "normal" flow in a pile of > error handling, and IMO is a lot harder to follow: > > foo, err := Foo() > if err != nil { > return fmt.Errorf("enforcing foo limit: %w", err)

Re: [go-nuts] Error Handling Question

On Mon, Oct 24, 2022 at 7:18 PM Ian Lance Taylor wrote: > On Sun, Oct 23, 2022 at 9:31 PM 'Daniel Lepage' via golang-nuts > wrote: > > ... > > > > 3. Streamlining shouldn't only apply to error handling that terminates > the function. > > > > Unlike panics, errors are values, and should be

Re: [go-nuts] Error Handling Question

On Mon, Oct 24, 2022, 9:03 PM robert engels wrote: > Totally understandable, but then I think the Go team should also drop any > proposals related to “improved error handling” - because you are going to > arrive back where you started - maybe with the a slightly different syntax > and that

Re: [go-nuts] Error Handling Question

Totally understandable, but then I think the Go team should also drop any proposals related to “improved error handling” - because you are going to arrive back where you started - maybe with the a slightly different syntax and that hardly seems worth the effort. Great engineering is built by

Re: [go-nuts] Error Handling Question

On Mon, Oct 24, 2022 at 8:49 PM Robert Engels wrote: > > I’ve read that many times and I don’t believe it holds much water. Even the > example cited about handling the inability to open a file - the function > can’t handle this because it does not know the intent which leads to the > > If err

Re: [go-nuts] Error Handling Question

I’ve read that many times and I don’t believe it holds much water. Even the example cited about handling the inability to open a file - the function can’t handle this because it does not know the intent which leads to the If err != nil { return err } boilerplate. This is exactly what

Re: [go-nuts] Error Handling Question

On Mon, Oct 24, 2022 at 5:57 PM Robert Engels wrote: > > But that highlights the value of exceptions - the non error path is very > clean. For example when writing a file - it often doesn’t matter the reason > it failed within the write function - could be an invalid path, illegal file > name

Re: [go-nuts] Error Handling Question

But that highlights the value of exceptions - the non error path is very clean. For example when writing a file - it often doesn’t matter the reason it failed within the write function - could be an invalid path, illegal file name , out of disk space. If the code is properly decomposed that

Re: [go-nuts] Error Handling Question

On Sun, Oct 23, 2022 at 9:31 PM 'Daniel Lepage' via golang-nuts wrote: ... > 3. Streamlining shouldn't only apply to error handling that terminates the > function. > > Unlike panics, errors are values, and should be treated as such, which means > that the calling function should be able to

Re: [go-nuts] Error Handling Question

ISTM that a lot of your arguments boil down to throwing two disparate things into the same pot: 1. Detecting and handling failure modes outside the current process, which have to be expected and should be dealt with gracefully by a correct program. 2. Limitations of Go's type system, which result

Re: [go-nuts] Error Handling Question

On Sun, Oct 23, 2022 at 1:08 AM Brian Candler wrote: > > And I agree that the above function is much easier to read and much > faster to write than the first version! But now I'm raising unchecked > exceptions instead of handling errors properly. > > However you're not "raising an unchecked

Re: [go-nuts] Error Handling Question

On Saturday, 22 October 2022 at 22:25:16 UTC+2 dple...@google.com wrote: > that the above function is much easier to read and much faster to write True but in my opinion not relevant because: 1. Time to write a function is almost negligible compare to its time needed for maintenance, rewrites,

Re: [go-nuts] Error Handling Question

> And I agree that the above function is much easier to read and much faster to write than the first version! But now I'm raising unchecked exceptions instead of handling errors properly. However you're not "raising an unchecked exception"; you're panicking, which is something different. Go

Re: [go-nuts] Error Handling Question

On Fri, Oct 21, 2022 at 12:30 PM Daniel Lepage wrote: > > > In that issue there was considerable resistance to having flow of control > > change as part of an expression. No other part of Go works that way: flow > > of control change is always a keyword, or a call to panic which can only > >

Re: [go-nuts] Error Handling Question

On Fri, Oct 21, 2022 at 5:57 PM Andrew Harris wrote: > Comparing 'panic' and 't.Fatal', they are similar in that there's no > notion of recovering and making further progress, they abruptly terminate > the process. Still, a wonky thing to say is that a 't.Fatal' call is > completely legitimate

Re: [go-nuts] Error Handling Question

On Fri, Oct 21, 2022 at 5:16 PM Robert Engels wrote: > Unchecked exceptions in Java denote programming errors or critical > unrecoverable errors. > Yes, that's exactly what I'm saying. This is what panics are used for in Go; if you have an error that is recoverable you ought to be returning an

Re: [go-nuts] Error Handling Question

Comparing 'panic' and 't.Fatal', they are similar in that there's no notion of recovering and making further progress, they abruptly terminate the process. Still, a wonky thing to say is that a 't.Fatal' call is completely legitimate as a form of "checked"-style error handling. It will log what

Re: [go-nuts] Error Handling Question

Unchecked exceptions in Java denote programming errors or critical unrecoverable errors. If these are being trapped/handled it is indicative of a system with design errors. (That being said, some programming errors can be ignored/handled at the request level - indicating that the chance any

Re: [go-nuts] Error Handling Question

> That aspect of this idea seems similar to the try proposal ( https://go.dev/issue/32437). Yes, I read over that proposal and the comments; it seemed like the biggest objections were: 1. handle() is very similar to defer/recover but not quite the same, which could be confusing (e.g. that a

Re: [go-nuts] Error Handling Question

On Thu, Oct 20, 2022 at 9:52 PM Daniel Lepage wrote: > > Sorry, I should have been clearer - what I am proposing is both try/handle > blocks and a `check` expression that triggers the handler. Sorry, I did miss the "check". That aspect of this idea seems similar to the try proposal

Re: [go-nuts] Error Handling Question

On Thu, Oct 20, 2022 at 5:36 PM Ian Lance Taylor wrote: > On Thu, Oct 20, 2022 at 2:14 PM 'Daniel Lepage' via golang-nuts > wrote: > > > > I'm not sure if this is the right forum to ask this question - please > let me know if there's somewhere better! > > > > I'm wondering why most of the Go 2

Re: [go-nuts] Error Handling Question

On Thu, Oct 20, 2022 at 2:14 PM 'Daniel Lepage' via golang-nuts wrote: > > I'm not sure if this is the right forum to ask this question - please let me > know if there's somewhere better! > > I'm wondering why most of the Go 2 error handling proposals I've seen are > intent on not letting a

[go-nuts] Error Handling Question

Hi all, I'm not sure if this is the right forum to ask this question - please let me know if there's somewhere better! I'm wondering why most of the Go 2 error handling proposals I've seen are intent on not letting a function continue after detecting an error - this seems weird to me, since we

Re: [go-nuts] Error Handling Proposal(s)

On Wed, Apr 28, 2021 at 2:29 PM Kaveh Shahbazian wrote: > > Is there a thread on proposals on error handling (with any chance to be > worked on, by the Go team)? > > Found this one by Russ Cox, but couldn't find any active threads on GitHub or > here. There are many error handling proposals.

[go-nuts] Error Handling Proposal(s)

Is there a thread on proposals on error handling (with any chance to be worked on, by the Go team)? Found this one by Russ Cox, but couldn't find any active threads on GitHub

Re: [go-nuts] Error handling

> > I realize that this thread ended up diverging into a wider discussion of > exceptions and error handling in general but I wanted mention one of the > problems I discovered and maybe a potential solution for others who may be > tempted to play around with something like this. > > I

Re: [go-nuts] Error handling

I’ll only add to this, there is no reason to close in the exception handler - it is automatic by the try-with-resource. The only reason to check null is if you needed to “do something else” based on that state. I think a better pattern with the “something else” is to always use standard

Re: [go-nuts] Error handling

This has been interesting to watch as I too have somehow been "converted" from java style exceptions to current go-style error flow as preference. In the first example you just shared, I think if you elaborate the comments, "at this point all files are open, if any fail, others are closed",

Re: [go-nuts] Error handling

If you're proposing exceptions, be aware of how complicated the control flow for correct handling can be. Look for what follows `The statement "RESULT = yield from EXPR" is semantically equivalent to...` in https://www.python.org/dev/peps/pep-0380/ -- You received this message because you are

Re: [go-nuts] Error handling

> On Feb 21, 2021, at 8:51 PM, Ian Davis wrote: > > On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote: >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? I have made the point a few times and it goes to crickets >> - I have to believe that is

Re: [go-nuts] Error handling

> On Feb 22, 2021, at 8:33 AM, Wojciech S. Czarnecki wrote: > > Dnia 2021-02-21, o godz. 11:23:24 > robert engels napisał(a): > >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? > > May you please explain the benefit of ‘checked exceptions’ over

Re: [go-nuts] Error handling

Dnia 2021-02-21, o godz. 11:23:24 robert engels napisał(a): > Can someone please explain the benefit of ‘error return’ over ‘checked > exceptions’ ? May you please explain the benefit of ‘checked exceptions’ over ‘return error value’? I stated and restated benefits of 'Go-way' earlier in

Re: [go-nuts] Error handling

That’s a very fair ask. I will work up some code and it will be interesting to see how much they actually differ. I do think that the differences will be more apparent in the handling of errors during processing - eg Scan() - than during resource acquisition/initialization. > On Feb 21,

Re: [go-nuts] Error handling

On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote: > Can someone please explain the benefit of ‘error return’ over ‘checked > exceptions’ ? I have made the point a few times and it goes to crickets > - I have to believe that is because there is none, or it is difficult > to communicate. >

Re: [go-nuts] Error handling

On Sun, Feb 21, 2021 at 3:01 PM robert engels wrote: > > > On Feb 21, 2021, at 3:17 PM, Ian Lance Taylor wrote: > > > > On Sun, Feb 21, 2021 at 9:23 AM robert engels wrote: > >> > >> Can someone please explain the benefit of ‘error return’ over ‘checked > >> exceptions’ ? I have made the point

Re: [go-nuts] Error handling

See below: > On Feb 21, 2021, at 3:17 PM, Ian Lance Taylor wrote: > > On Sun, Feb 21, 2021 at 9:23 AM robert engels wrote: >> >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? I have made the point a few times and it goes to crickets - I >> have to

Re: [go-nuts] Error handling

On Sun, Feb 21, 2021 at 9:23 AM robert engels wrote: > > Can someone please explain the benefit of ‘error return’ over ‘checked > exceptions’ ? I have made the point a few times and it goes to crickets - I > have to believe that is because there is none, or it is difficult to > communicate.

Re: [go-nuts] Error handling

Can someone please explain the benefit of ‘error return’ over ‘checked exceptions’ ? I have made the point a few times and it goes to crickets - I have to believe that is because there is none, or it is difficult to communicate. The ‘handle where they occur claim’ is weak, as you can handle

Re: [go-nuts] Error handling

Dnia 2021-02-20, o godz. 16:48:09 Michael MacInnis napisał(a): > I can tell you most emphatically that I am not proposing not checking > and/or not handling errors. I did not stated that you won't. Cited piece was directed at "just return err" code stressing that it is not that common in the

Re: [go-nuts] Error handling

I don't believe anyone is talking about not handling errors. There are functions that perform a sequence of actions and need to go no further when an error is encountered. An example of this type of function is presented in the "Errors are Values" post:

Re: [go-nuts] Error handling

Dnia 2021-02-20, o godz. 13:21:09 Michael Ellis napisał(a): > FWIW, I've put together a tiny package that, with some tradeoffs, seems > useful for reducing boilerplate in the common case where a function simply > wants to return an error to its caller. > The code is almost trivial. It

Re: [go-nuts] Error handling

Neat. What you and I are doing is very similar. Particularly how the handler is "bound" to the error and checks to make sure that the error is non-nil before attempting to recover. The differences I see in our approaches are as follows: I support wrapping an error or performing some arbitrary

Re: [go-nuts] Error handling

Some developers build sheds others build skyscrapers. Exceptions let you build skyscrapers - but not everyone needs a skyscraper. I’ve use both methods extensively in my career - well written exception code is far easier to write and maintain for more complex systems. > On Feb 20, 2021, at

Re: [go-nuts] Error handling

I consider checked vs unchecked exceptions “well written” or even valid code. Checked exceptions are similar to Gos error return except more/easier/better? compile and coding time validation. Unchecked exceptions are similar to panic recover except you have more information. There is no

Re: [go-nuts] Error handling

FWIW, I've put together a tiny package that, with some tradeoffs, seems useful for reducing boilerplate in the common case where a function simply wants to return an error to its caller. https://github.com/Michael-F-Ellis/ro The code is almost trivial. It consists of two small functions,

Re: [go-nuts] Error handling

I'm referring to errors found in the function (i.e., by calling other functions). It's the responsibility of the callers of a function to handle the errors it returns, and not the function itself. How can one function claim responsibility for the error handling strategy of all programs using it?

Re: [go-nuts] Error handling

On Sat, Feb 20, 2021 at 12:11 PM Robert Engels wrote: > > Can you clarify what you mean mean by “the code does exactly what it shows on > the page”? How do you know by looking at the code, or even compiling the > code, that all possible errors returned by a function are handled? That to me >

Re: [go-nuts] Error handling

Can you clarify what you mean mean by “the code does exactly what it shows on the page”? How do you know by looking at the code, or even compiling the code, that all possible errors returned by a function are handled? That to me is biggest difficult in reading (or using) others Go code.

Re: [go-nuts] Error handling

Roger beat me to it. But allow me to rephrase, "The users of Go for a long time have resisted any changes to its simple, clear method of error handling despite it being a major concern of folks who don't use Go much." * * I'm referring to the original survey, which was worded along the lines of

Re: [go-nuts] Error handling

On Sat, 20 Feb 2021, 16:31 L Godioleskky, wrote: > Rust lang, very early in its evolution, saw the need to create its > operator '?' to more efficiently manage error handling. But the guardians > of Go lang have resisted any changes to its clumsy method of error handling > despite it being a

Re: [go-nuts] Error handling

Rust lang, very early in its evolution, saw the need to create its operator '?' to more efficiently manage error handling. But the guardians of Go lang have resisted any changes to its clumsy method of error handling despite it being a major concern of Go users for a very long time. On

Re: [go-nuts] Error handling

There's no crossfire :) I think most of the issues I have can probably be addressed with some standardized packages without converting panic/recover into full-blown exceptions and making them the default. The key is “standardized”, which is why I’m sad to see lack of progress towards a new

Re: [go-nuts] Error handling

At the risk of getting caught in the crossfire, I will point out again that I just found it interesting how close it was possible to get to something like check/handle with just standard language constructs. If you'll excuse the cuddled checks, I think this: func CopyFile(src, dst string)

Re: [go-nuts] Error handling

Yes but without robust error information (stack trace, typed error) it is very hard to write that top-level handler - at least not a robust one. Plus you are relying on the proper use of defer etc up the chain. This is much simpler with exceptions - to me anyway. > On Feb 18, 2021, at 10:39

Re: [go-nuts] Error handling

>don’t think ‘single shot, short lived processes’ are the typical Go >paradigm - they are usually larger , multi layer, long lived “server” >processes. It’s my opinion that Gos error handling is a problem for >these types. I am not saying it can’t be done but it’s harder to

Re: [go-nuts] Error handling

To clarify, the Java like/runtime reference I made does not strictly refer to startup costs - I am also referring to runtime costs as in additional threads for GC, housekeeping, overall binary size, etc. I don’t think ‘single shot, short lived processes’ are the typical Go paradigm - they are

Re: [go-nuts] Error handling

On Thursday, 18 February 2021 at 09:34:35 UTC+1 Amnon wrote: > OT, but what has happened to the Go 2 error handling proposals? > I heard that the original check proposal was abandoned because of the > unfortunate interaction with defer. > > Any updates? After the "check" proposal the Go team

Re: [go-nuts] Error handling

On 2/18/21 4:01 AM, robert engels wrote: > But - the issue is that most of the time - for complex systems - the errors > cannot be handled where they are encountered - even in Go, most of the error > handling becomes boilerplate returning the error detected and expecting some > higher level to

Re: [go-nuts] Error handling

On Thursday, 18 February 2021 at 04:01:47 UTC ren...@ix.netcom.com wrote: > Go - whether people like this or not - is VERY close to Java (because of > the “runtime”) - and both suffer from “runtime overhead/startup cost” > I have used one-shot Java CLI tools that take literally 4 or 5 seconds

Re: [go-nuts] Error handling

OT, but what has happened to the Go 2 error handling proposals? I heard that the original check proposal was abandoned because of the unfortunate interaction with defer. Any updates? On Thursday, 18 February 2021 at 08:30:26 UTC ntr...@gmail.com wrote: > What would be the difference between

Re: [go-nuts] Error handling

What would be the difference between using exceptions/deferring a generalized error wrapping, and panic-recover? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [go-nuts] Error handling

But - the issue is that most of the time - for complex systems - the errors cannot be handled where they are encountered - even in Go, most of the error handling becomes boilerplate returning the error detected and expecting some higher level to handle it. With exceptions this is enforced, or

Re: [go-nuts] Error handling

I actually prefer the explicit error handling: ``` f, err := os.Open("path") if err != nil { //handle error } ``` When you are reading the code to look whether a certain condition has been handled, the explicit branching statement makes it easier to scan. On Wednesday, February 17, 2021 at

Re: [go-nuts] Error handling

I wanted to express my thanks to Mickael McKinnus for his research. I am someone who is quite happy with the error handling in Go as it lets me implement whatever I like, I must say it is obviously flawed from the standpoint that the proper constructs are not part of the language but part of

Re: [go-nuts] Error handling

And I will tell you that after working with error returns and exceptions, exceptions are superior - but much depends on the complexity of the system. For small system level tools that are pieced together via pipes, C error handling is fine - because the process serves as the exception handling

Re: [go-nuts] Error handling

I do sometimes do something similar, but without the check() function. The exit points are explicit, it is guaranteed that errors will be wrapped. func do(name string) (err error) { defer PWrapf(, "do(%s)", name) s, err := works(name); if err != nil {

Re: [go-nuts] Error handling

I think there is strong consensus, that the current style of error handling is currently the best option. Nobody has been able to come up with something better (really better, not just more comfortable while ignoring hefty drawbacks). It is true that a loud minority seems to miss exceptions to

Re: [go-nuts] Error handling

> > Go helps with that. Even team's proposal was finally retracted: > https://github.com/golang/go/issues/32437 Discussion there is lengthy, > but worth > reading to sense why wider community considers "boilerplate" as asset. > Thanks, I did follow the try proposal and the earlier

Re: [go-nuts] Error handling

I think ’strong census’ is not accurate - thus the discussions around improving error handling in Go2. Many have commented here and elsewhere that the number one reason they don’t use Go is due to lack of exception handling. > On Feb 14, 2021, at 10:12 AM, Wojciech S. Czarnecki wrote: > >

Re: [go-nuts] Error handling

Dnia 2021-02-13, o godz. 17:44:47 Michael MacInnis napisał(a): > I've been playing around with reducing error handling boilerplate You're not alone. Hundreds of us went into such thinking in the first weeks of reading/using Go - yet before we noticed how much more productive we are with Go's

[go-nuts] Error handling

I've been playing around with reducing error handling boilerplate using standard language constructs. I'm currently doing something that looks like this: import ( "github.com/michaelmacinnis/handle" ) func do(name string) (err error) { check, handle :=

[go-nuts] [error handling] RFC 'else'

Do I understand correctly that "last return value is error" is purely convention and there is no formal error handling in current go? My instinct is to leverage the 'else' keyword along with the notion of a "stock error whose return list's last element is type error with value != nil. func

Re: [go-nuts] error handling proposals summary

On Wed, Nov 25, 2020 at 3:10 PM seank...@gmail.com wrote: > > For some reason I thought going through most of the error handling proposals > would be a nice way to spend the evening (note I now mostly regret this). If > anyone wants to see how similar they are: >

[go-nuts] error handling proposals summary

For some reason I thought going through most of the error handling proposals would be a nice way to spend the evening (note I now mostly regret this). If anyone wants to see how similar they are: https://seankhliao.com/blog/12020-11-23-go-error-handling-proposals/ -- You received this message

Re: [go-nuts] Error Handling in Go 2

In that proposal, some more syntax and semantics are being added - IMHO. One problem here is the name of the error variable. Here we explicitly have to used named return values - no new syntax there. And return() and panic() on left side, only accept error type. They will only be triggered when

Re: [go-nuts] Error Handling in Go 2

On Wed, Jul 29, 2020 at 7:46 AM Kaveh Shahbazian wrote: > > Go can already pass/pipe the result of a function, which returns multiple > values, to another function, which accepts the same values as arguments. A > similar mechanism can be used for handling errors, by passing/pipe them to a >

[go-nuts] Error Handling in Go 2

Go can already pass/pipe the result of a function, which returns multiple values, to another function, which accepts the same values as arguments. A similar mechanism can be used for handling errors, by passing/pipe them to a special construct. Now, assume we have a function named funcCtx:

Re: [go-nuts] Error Handling Best Practice (error wrapping)

Let's please all drop this thread. Thanks. Chris, sorry this got derailed. If you want to follow up on something please start a new thread. Thanks. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] Error Handling Best Practice (error wrapping)

One other thing. I’ll say it again. Go is an amazing piece of technology and it is awesome for many type of applications. I think the “fracturing” that may be occurring is because people are using it in cases it is not well suited and they are running into walls, thus the need to add in

  1   2   >