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 typing

Re: [go-nuts] Re: Error handling

On Tue, Aug 1, 2023 at 1:47 AM DrGo wrote: > The verbosity of error handling is the number one concern for Go developers > in the most recent survey. That says something about those developers, about their preferences, opinions, taste etc and that it differs from what the Original Language Desi

Re: [go-nuts] Re: Error handling

I don't think this argument holds much weight. I understand and agree that the majority is not always correct. But then what was the point of the developer survey, if that data is irrelevant? Isn't the existence of the developer survey an implicit statement by the Go team that they care about

Re: [go-nuts] Re: Error handling

I think that the original Author has made a clear point. It has no sense to denied that we often write a lot of times things like... if (err != nil) { return err } So, I understand that some people doesn't bother about that, and that is okey. *But for those that doesn't like to write someth

[go-nuts] Re: Error handling

Thanks. The keystroke saving is not the motivation. The aim is to reduce the code reader’s mental load. My approach allows for clearer code where the main program logic is not dwarfed by the error handling code while maintaining the explicitly of error handling and the possible error-induced i

[go-nuts] Re: Error handling

On Tuesday, 1 August 2023 at 18:06:25 UTC+1 DrGo wrote: Compare the following; which one would you prefer to read a lot of? You've asked a fair question so you deserve an honest answer. Looking at the two examples, I would prefer to read the code in the first example. -- You received this m

Re: [go-nuts] Re: Error handling

Thanks Tim for patiently explaining your perspective. Much appreciated. Please see my reply to Marcelo H showing using real life code that the outcome goes much further than replacing the err!= nil bit. On Monday, July 31, 2023 at 7:20:18 PM UTC-6 Tim Casey wrote: > > >> You do not think thi

Re: [go-nuts] Re: Error handling

Thanks Jan Indeed the majority can be wrong but in this case the OLD smart minority too wanted a way to improve things. This approach was in fact dictated by their requirements On Tuesday, August 1, 2023 at 2:10:57 AM UTC-6 Jan Mercl wrote: > On Tue, Aug 1, 2023 at 1:47 AM DrGo wrote: > > > T

[go-nuts] Re: Error handling

Fair enough. But many would prefer shorter functions if there is no loss to explicitness or clarity. On Tuesday, August 1, 2023 at 11:10:30 AM UTC-6 Stephen Illingworth wrote: > On Tuesday, 1 August 2023 at 18:06:25 UTC+1 DrGo wrote: > > Compare the following; which one would you prefer to read

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 A

[go-nuts] Re: Error handling

On Tuesday, 1 August 2023 at 18:14:56 UTC+1 DrGo wrote: Fair enough. But many would prefer shorter functions if there is no loss to explicitness or clarity. I don't think putting the assignment and return statement on the same line is very clear. I would prefer the compiler to enforce somethi

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 golang-nuts+unsubscr...@googlegr

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 we

[go-nuts] [security] Go 1.20.7 and Go 1.19.12 are released

Hello gophers, We have just released Go versions 1.20.7 and 1.19.12, minor point releases. These minor releases include 1 security fixes following the security policy : - crypto/tls: restrict RSA keys in certificates to <= 8192 bits Extremely large RSA ke

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

[go-nuts] failed fuzz tests not reproducible when re-run

Dear all, Recently I find quite often that after "go test -fuzz" reported an error, the command shown to re-run the test does not reproduce the failure. For example, just now I got the following: voss@dumpling [..nt/tounicode2] go test -fuzz FuzzToUnicode fuzz: elapsed: 0s, gathering baseline

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 pe