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

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] 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

[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

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

[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

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] 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

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: > > >

[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

[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

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

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

[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

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