Re: [go-nuts] Error handling

[Marcello H]

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.

```
result, err := makeSomeNoise() *orelse* {
DoSomethingElse()
}
```
vs
```
result, err := makeSomeNoise() if err != nil {
DoSomethingElse()
}
```
Ehm, this saves 16-9 = 7 keyboard entries.
If you ask me, this still reads consistent with the "normal" way we handle
errors.

What happens if all of a sudden, the makeSomeNoise returns 2 errors? Then
you have to undo the orelse construction, for what I understand.

The more I think of this, the more I like to type those extra keyboard
entries  to have a clear look about what happens in the program.

Just my 2 cents




Op di 1 aug 2023 om 03:31 schreef robert engels :

> 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 designers do not want exceptions in any way shape or form, so
> you’re pretty much going to be stuck with what you have (all of the decent
> proposals are “exception like”- exceptions by another name) so learn to
> love it or use a different language.
>
> On Jul 30, 2023, at 2:02 AM, Brian Candler  wrote:
>
> Just to be clear: are you hard-coding the variable name "err" into the
> semantics of "orelse"?  That is, you can't assign the error return to a
> variable of any other name?
>
> I disagree that this makes the job of linters any easier than it is
> today.  For example, if you'd written
>
> ...
>err = io.Copy(w, r)
> err = w.Close() orelse return err
> }
>
> then you'd still need to detect "value assigned but not used" in the
> linter (assuming it doesn't become *compulsory* to use "orelse" on any
> assignment to a variable called "err")
>
> On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote:
>
>> 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 syntactic
>> sugar for an "if err!=nil" block.
>>
>> The example code in Russ Cox's paper[1] will look something like this:
>>
>> func CopyFile(src, dst string) error {
>> r, err := os.Open(src) orelse return err
>> defer r.Close()
>> w, err := os.Create(dst) orelse return err
>> defer w.Close()
>>   err = io.Copy(w, r) orelse return err
>> err = w.Close() orelse return err
>> }
>>
>> It is an error to not return an error from an orelse block.
>>
>> In my eyes, this has the same explicitness and flexibility of the current
>> style but is significantly less verbose. It permits ignoring the error,
>> returning it as is or wrapping it. Because orelse is not used for any other
>> purpose, it would be easy for reviewers and linters to spot lack of error
>> handling.
>>
>> It also works well with named returns. e.g.,
>>
>> func returnsObjorErro() (obj Obj, err error) {
>>   obj, err := createObj() orelse return  //returns nil and err
>> }
>>
>> otherwise orelse is like "else" so e.g., it can be followed by a block if
>> additional cleanup or error formatting etc is needed before returning, eg
>> w, err := os.Create(dst) orelse {
>>   
>>   return err
>> }
>>
>> Similarity to "else" hopefully means that it is easy to learn. It is
>> obviously backward compatible
>>
>> What do you think?
>>
>> [1]
>> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
>>
>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/330e88d9-8072-4614-ae56-8ce9c59517f3n%40googlegroups.com
> 
> .
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/dRLR4hxxI8A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/60596671-D3AC-49D4-8575-F8EB3D9B6BF6%40ix.netcom.com
> 

Re: [go-nuts] Re: Error handling

[Jan Mercl]

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 Designers (OLD™) preferred.

It has close to zero bits of information which preferences are the
better ones. It's a subjective category anyway.

> So there is a need for doing something about it..

And here's IMO the mistake. You may feel the need, Joe and Mary may
not. It's ok to have preferences. It's ok for preferences to be
different. It does not mean there's a need to change anything. Of
course, you can decide that following the preferences of a majority of
developers is a rational move.

I claim it a fallacy. A big one. Let me not joke about billion flies,
but the fact is - language designers are few and far between while
developers come in heaps. And let's be honest. Most developers write
horrible code, me included. Maybe you're the rare exception, congrats
then. But the majority of us are just the ordinary, average coders for
hire. There are deadlines to meet, bills to pay, project mis-managers
getting into the way etc. We have all experienced that, didn't we?

I, for one learned to pay much more attention to what language
designers do and say. Sometimes I agree, sometime I don't. But I
believe one can, in essence, ignore what the majority of developers
thinks about it. Actually, I think the majority of developers is wrong
more often than the, most of the time silent, minority.

-j

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UNPFRR55YYJgWs34jh38p1zf61PpZaWFGiH2_khv1kbg%40mail.gmail.com.

Re: [go-nuts] Re: Error handling

[Jeremy French]

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 
what Go developers think?  There is also a very similar argument here which 
was central to the generics debate and was one of the major arguments in 
favor of implementing generics - that it would significantly help some 
people, and it wouldn't hurt anyone else very much.  So similarly, "I don't 
mind it the way it is" is not a very good argument.  

I don't speak for the Go team, but my impression is that they do care about 
this issue, and would like to reduce the boilerplate/verbosity of error 
handling if they could.  But that they have seen hundreds of different 
proposals (thousands if you include variations on a theme), and haven't 
found any that qualify for the requirements that are more important to Go's 
nature than just verbosity.

On Tuesday, August 1, 2023 at 4:10:57 AM UTC-4 Jan Mercl wrote:

> 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 Designers (OLD™) preferred.
>
> It has close to zero bits of information which preferences are the
> better ones. It's a subjective category anyway.
>
> > So there is a need for doing something about it..
>
> And here's IMO the mistake. You may feel the need, Joe and Mary may
> not. It's ok to have preferences. It's ok for preferences to be
> different. It does not mean there's a need to change anything. Of
> course, you can decide that following the preferences of a majority of
> developers is a rational move.
>
> I claim it a fallacy. A big one. Let me not joke about billion flies,
> but the fact is - language designers are few and far between while
> developers come in heaps. And let's be honest. Most developers write
> horrible code, me included. Maybe you're the rare exception, congrats
> then. But the majority of us are just the ordinary, average coders for
> hire. There are deadlines to meet, bills to pay, project mis-managers
> getting into the way etc. We have all experienced that, didn't we?
>
> I, for one learned to pay much more attention to what language
> designers do and say. Sometimes I agree, sometime I don't. But I
> believe one can, in essence, ignore what the majority of developers
> thinks about it. Actually, I think the majority of developers is wrong
> more often than the, most of the time silent, minority.
>
> -j
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7efa2d28-44c6-4089-b28a-90fe770a9003n%40googlegroups.com.

Re: [go-nuts] Re: Error handling

[Victor Giordano]

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 something twice, I guess 
your proposal is a good idea and highlights a boilerplate aspect across any 
golang project.*

Great Idea Dr Go!



El martes, 1 de agosto de 2023 a las 10:32:58 UTC-3, Jeremy French escribió:

> 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 what Go developers think?  There is also a very similar argument here 
> which was central to the generics debate and was one of the major arguments 
> in favor of implementing generics - that it would significantly help some 
> people, and it wouldn't hurt anyone else very much.  So similarly, "I don't 
> mind it the way it is" is not a very good argument.  
>
> I don't speak for the Go team, but my impression is that they do care 
> about this issue, and would like to reduce the boilerplate/verbosity of 
> error handling if they could.  But that they have seen hundreds of 
> different proposals (thousands if you include variations on a theme), and 
> haven't found any that qualify for the requirements that are more important 
> to Go's nature than just verbosity.
>
> On Tuesday, August 1, 2023 at 4:10:57 AM UTC-4 Jan Mercl wrote:
>
>> 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 Designers (OLD™) preferred. 
>>
>> It has close to zero bits of information which preferences are the 
>> better ones. It's a subjective category anyway. 
>>
>> > So there is a need for doing something about it.. 
>>
>> And here's IMO the mistake. You may feel the need, Joe and Mary may 
>> not. It's ok to have preferences. It's ok for preferences to be 
>> different. It does not mean there's a need to change anything. Of 
>> course, you can decide that following the preferences of a majority of 
>> developers is a rational move. 
>>
>> I claim it a fallacy. A big one. Let me not joke about billion flies, 
>> but the fact is - language designers are few and far between while 
>> developers come in heaps. And let's be honest. Most developers write 
>> horrible code, me included. Maybe you're the rare exception, congrats 
>> then. But the majority of us are just the ordinary, average coders for 
>> hire. There are deadlines to meet, bills to pay, project mis-managers 
>> getting into the way etc. We have all experienced that, didn't we? 
>>
>> I, for one learned to pay much more attention to what language 
>> designers do and say. Sometimes I agree, sometime I don't. But I 
>> believe one can, in essence, ignore what the majority of developers 
>> thinks about it. Actually, I think the majority of developers is wrong 
>> more often than the, most of the time silent, minority. 
>>
>> -j 
>>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/227a8423-b52a-47d7-acc4-f47280b2898dn%40googlegroups.com.

[go-nuts] Re: Error handling

[DrGo]

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 
interruption in program flow. It avoids creating new if scope when one is 
not desired and offers opportunities for further deduplication of error 
handling code although each error is still handled individually. Compare 
the following; which one would you prefer to read a lot of?

- current approach; error handling to program logic ratio: 13:5 

func CopyFile(src, dst string) error {
r, err := os.Open(src)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
defer r.Close()

w, err := os.Create(dst)
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

if _, err := io.Copy(w, r); err != nil {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

if err := w.Close(); err != nil {
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
}

- new approach ratio 5:5
func CopyFile(src, dst string) error {
r, err := os.Open(src) *orelse* return fmt.Errorf("copy %s %s: %v", src, 
dst, err)
defer r.Close()

w, err := os.Create(dst); *orelse* return fmt.Errorf("copy %s %s: %v", src, 
dst, err)
err := io.Copy(w, r) *orelse* {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

err := w.Close() *orelse* {
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
}

On Sunday, July 30, 2023 at 9:27:27 PM UTC-6 Marcello H wrote:

> I think the current error handling is just fine.
> For the extra typing, they invented keyboard snippets and such.
>
> But for this proposal, I would like to see how a return with multiple 
> values would look to get a better understanding.
> ```
> // translate this in the proposed solution?
> func myFirstFunction() (string, err) {
>result, err := myFunction()
>if err != nill {
>return rest, err
>}
> }
> ```
>
> Op maandag 31 juli 2023 om 04:32:01 UTC+2 schreef DrGo:
>
>> Another possibility Jeremy is that the orelse block is executed if any of 
>> the returned error values is not nil. 
>>
>> On Sunday, July 30, 2023 at 8:14:58 PM UTC-6 DrGo wrote:
>>
>>> Thanks...
>>> yes indeed. Too many requirements but I think this solution comes close 
>>> to meeting them. If a rare function returns more than one error value (yet 
>>> to see one in the wild) then the compiler should reject orelse use and the 
>>> user can fallback on the (the if err!= nil) approach. 
>>>
>>> On Sunday, July 30, 2023 at 6:02:57 PM UTC-6 Jeremy French wrote:
>>>
 Also, errors are values, which means - although uncommon - a function 
 could return two or more error values.  Which would orelse evaluate?  Even 
 if you arbitrarily chose one, that would violate the explicit vs implicit 
 code flow principle.  

 My sympathies, OP.  I too hate the "if err!= nil" boilerplate, and have 
 suggested my own idea for fixing it, which was similarly dismantled for 
 good reasons by those more knowledgeable than me.  The truth is, this 
 problem/issue has so many restrictions placed on it (currently idiomatic 
 principles, backwards compatibility promise, explicit vs implicit, etc) 
 that the set of possible solutions is VERY narrow, possibly infinitely so.

 On Sunday, July 30, 2023 at 3:51:49 PM UTC-4 Brian Candler wrote:

 err := io.Copy(w, r) *orelse* {
 w.Close()
 os.Remove(dst)
 return fmt.Errorf("copy %s %s: %v", src, dst, err)
 }

 My question still stands. Semantically, what value exactly does the 
 "orelse" condition test is not equal to nil?

 - does it test the value from the preceding assignment? If so, is 
 "orelse" only valid immediately following an assignment expression? The 
 original posting didn't say this.  And if it *is* linked to an assignment 
 expression which assigns multiple values, does it only look at the last 
 value? (Again, that was not specified)

 - does it always test a variable called "err"? The original posting 
 said it was equivalent to "if err!=nil" but a later post contradicted this

 - does it test the value from the 'return' expression at the end of the 
 block following orelse? Except in this case, it can't because it's buried 
 inside fmt.Errorf

 On Sunday, 30 July 2023 at 17:55:34 UTC+1 DrGo wrote:

 Good point Harri,

 This is what the correct version will look like using this proposal 

 func CopyFile(src, dst string) error {
 r, err := os.Open(src) *orelse* return fmt.Errorf("copy %s %s: %v", 
 src, dst, err)
 defer r.Close()

 w, err := os.Create(dst); *orelse* return fmt.Errorf("copy %s %s: %v", 
 src, dst, err)
 err := io.Copy(w, r) *orelse* {
 w.Close()
 os.Remov

[go-nuts] Re: Error handling

[Stephen Illingworth]

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 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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5c32bdce-b07c-4703-b445-4a2a2d95a0f5n%40googlegroups.com.

Re: [go-nuts] Re: Error handling

[DrGo]

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 this is a significant  reduction in boilerplate?
>
> I understand people having a complaint about the verbosity of error 
> handling.  But, this follows C code error handling.  So to me, it is not 
> all *that* bad.  
> I think the measurable reduction in boilerplate code is ' ; err != nil' 
> for ' orelse '.   And I do not believe this is worth a keyword.  Some of 
> the context is  being used to C.  And another aspect is being used to perl 
> and its one liners.  With perl, the debugger is not something which is 
> close to gdb/adb or the like.  So the comparison is not about saving code.
>
> I would suggest, if I had a bold idea (and probably dumb), to have a 
> functional way to handle this.   Something like:
>
> HandleErrorChain( todoList []func() (TYPE,error), errorHandler func () 
> TYPE, error ) (TYPE, error)
>
> Which means, I have a list of things I want to do and I want the error 
> handling to be all the same for all of them.  Then the *chain* of things 
> would make sense with a single handler.  This has the expense of being 
> kinda odd so at the very least it would need idiomatic polishing.  I also 
> think I am too ignorant to have a real say in any of this.
>
> >> Why it won't work with one time retires? That is like one time retires 
> won't work in an if-else block
>
> I think there is a bit of talking past each other here.  Or at least I 
> dont understand.  I think orelse is too specific to be helpful.  That is, 
> it is too precise to reduce a large swath of what might look like error 
> handling code, because error handling code can at times be specific.  The 
> first dumb example I came up with is a simple one-time retry, which I have 
> put in code at times.  It is usually ugly, but effective:
>
> v,err := dosomething()
> if err != nil {
> v,err = dosomething()
> }
> if err != nil {
> handleError(err)
>}
>importantOperation(v)
>
> This with the token:
>
> if v,err := dosomething() orelse {
> v,err = dosomething() orelse {
> handleError()
> }
> }
> importantOperation(v)
>
> The savings is the two 'err != nil' lines.
>
> If I take a step back, some of what I am reacting to is how much it is 
> discussed.  It *feels*, at least to me as an ignorant person in this 
> context, as if people were not handling errors previously.  Golang is 
> forcing this now and the resulting lines of code look like 'too much' 
> compared to previous lines of code.  But I think this is a direct design 
> goal.  If the keyword vs lines of code/tokenspace is worth it, so be it.  
> Who am I to say.  If we are truely circling on a way to handle errors in a 
> chain, then the chain aspect is at least as important as any one line, and 
> up to this point has largely been ignored.
>
> In any event, i dont mean to be argumentative or even contrarian.  Sorry 
> if it comes across that way.
>
> tim
>
>
> On Mon, Jul 31, 2023 at 4:46 PM DrGo  wrote:
>
>> Thanks for the valuable feedback,
>> The verbosity of error handling is the number one concern for Go 
>> developers in the most recent survey. So there is a need for doing 
>> something about it.. except that there are many possibly conflicting 
>> requirements outlined by the Go team. 
>> The problem with the abbreviated if err!= nil in your example:
>>   if x,err := something() ; err != nil {
>> handleErrorAndReturn
>> }
>> is that x is local to the if scope and often that won't work forcing the 
>> more verbose:
>>x,err := something()
>>   if err != nil {
>> handleErrorAndReturn
>> } 
>> If you have few of those as is the case in io programs; there is real 
>> impact on the readability of the code.
>> the oresle approach avoids that problem (the x stays in the scope of the 
>> func).
>>
>>x,err := something() orelse {
>> handleErrorAndReturn
>> } 
>> You do not think this is a significant  reduction in boilerplate? The 
>> only thing that will do a better job is a try-catch which is not acceptable 
>> to the Go team (fortunately). 
>>
>> why the line-by-line would break with orelse? they are working fine with 
>> the one-liner you cited:
>>   if x,err := something() ; err != nil 
>>
>> Why it won't work with one time retires? That is like one time retires 
>> won't work in an if-else block.
>>
>> Thanks again,
>>
>> On Monday, July 31, 2023 at 3:59:50 PM UTC-6 Tim Casey wrote:
>>
>>>
>>>
>>> I do not think this reduces boilerplate code.  This compacts it, which 
>>> is different.
>>>
>>> I think any one-liner-return-on-err makes the language harder to debug.  
>>> It is very common breakpoints are set for exceptional cases, which tend to 
>>> be 

Re: [go-nuts] Re: Error handling

[DrGo]

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:
>
> > 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 Designers (OLD™) preferred.
>
> It has close to zero bits of information which preferences are the
> better ones. It's a subjective category anyway.
>
> > So there is a need for doing something about it..
>
> And here's IMO the mistake. You may feel the need, Joe and Mary may
> not. It's ok to have preferences. It's ok for preferences to be
> different. It does not mean there's a need to change anything. Of
> course, you can decide that following the preferences of a majority of
> developers is a rational move.
>
> I claim it a fallacy. A big one. Let me not joke about billion flies,
> but the fact is - language designers are few and far between while
> developers come in heaps. And let's be honest. Most developers write
> horrible code, me included. Maybe you're the rare exception, congrats
> then. But the majority of us are just the ordinary, average coders for
> hire. There are deadlines to meet, bills to pay, project mis-managers
> getting into the way etc. We have all experienced that, didn't we?
>
> I, for one learned to pay much more attention to what language
> designers do and say. Sometimes I agree, sometime I don't. But I
> believe one can, in essence, ignore what the majority of developers
> thinks about it. Actually, I think the majority of developers is wrong
> more often than the, most of the time silent, minority.
>
> -j
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bdee0b89-2098-4c32-b6a5-8cb3aa54abccn%40googlegroups.com.

[go-nuts] Re: Error handling

[DrGo]

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 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 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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/807cc6b3-49d8-43b1-b35f-ba711c82822cn%40googlegroups.com.

Re: [go-nuts] Error handling

[DrGo]

>> 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 AM UTC-6 Marcello H wrote:

> 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.
>
> ```
> result, err := makeSomeNoise() *orelse* {
> DoSomethingElse()
> }
> ```
> vs
> ```
> result, err := makeSomeNoise() if err != nil {
> DoSomethingElse()
> }
> ```
> Ehm, this saves 16-9 = 7 keyboard entries.
> If you ask me, this still reads consistent with the "normal" way we handle 
> errors.
>
> What happens if all of a sudden, the makeSomeNoise returns 2 errors? Then 
> you have to undo the orelse construction, for what I understand.
>
> The more I think of this, the more I like to type those extra keyboard 
> entries  to have a clear look about what happens in the program.
>
> Just my 2 cents
>
>
>
>
> Op di 1 aug 2023 om 03:31 schreef robert engels :
>
>> 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 designers do not want exceptions in any way shape or form, so 
>> you’re pretty much going to be stuck with what you have (all of the decent 
>> proposals are “exception like”- exceptions by another name) so learn to 
>> love it or use a different language.
>>
>> On Jul 30, 2023, at 2:02 AM, Brian Candler  wrote:
>>
>> Just to be clear: are you hard-coding the variable name "err" into the 
>> semantics of "orelse"?  That is, you can't assign the error return to a 
>> variable of any other name?
>>
>> I disagree that this makes the job of linters any easier than it is 
>> today.  For example, if you'd written
>>
>> ...
>>err = io.Copy(w, r)
>> err = w.Close() orelse return err
>> }
>>
>> then you'd still need to detect "value assigned but not used" in the 
>> linter (assuming it doesn't become *compulsory* to use "orelse" on any 
>> assignment to a variable called "err")
>>
>> On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote:
>>
>>> 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 syntactic 
>>> sugar for an "if err!=nil" block.
>>>
>>> The example code in Russ Cox's paper[1] will look something like this:
>>>
>>> func CopyFile(src, dst string) error {
>>> r, err := os.Open(src) orelse return err 
>>> defer r.Close()
>>> w, err := os.Create(dst) orelse return err
>>> defer w.Close()
>>>   err = io.Copy(w, r) orelse return err
>>> err = w.Close() orelse return err
>>> }
>>>
>>> It is an error to not return an error from an orelse block.
>>>
>>> In my eyes, this has the same explicitness and flexibility of the 
>>> current style but is significantly less verbose. It permits ignoring the 
>>> error, returning it as is or wrapping it. Because orelse is not used for 
>>> any other purpose, it would be easy for reviewers and linters to spot lack 
>>> of error handling.  
>>>
>>> It also works well with named returns. e.g., 
>>>
>>> func returnsObjorErro() (obj Obj, err error) {
>>>   obj, err := createObj() orelse return  //returns nil and err
>>> } 
>>>
>>> otherwise orelse is like "else" so e.g., it can be followed by a block 
>>> if additional cleanup or error formatting etc is needed before returning, 
>>> eg 
>>> w, err := os.Create(dst) orelse {
>>>   
>>>   return err 
>>> }
>>>
>>> Similarity to "else" hopefully means that it is easy to learn. It is 
>>> obviously backward compatible  
>>>
>>> What do you think?
>>>
>>> [1] 
>>> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
>>>
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/330e88d9-8072-4614-ae56-8ce9c59517f3n%40googlegroups.com
>>  
>> 
>> .
>>
>>
>> -- 
>>
> You received this message because 

[go-nuts] Re: Error handling

[Stephen Illingworth]

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 something like the following:

func CopyFile(src, dst string) error {
r, err := os.Open(src) *orelse* {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
defer r.Close()

w, err := os.Create(dst) *orelse* {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
err := io.Copy(w, r) *orelse* {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

err := w.Close() *orelse* {
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
}

What do you intend to happen to the error instances after the orelse block? 
Are they valid outside the orelse block?


-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6dd26b81-23b3-4226-9eb9-3bc47b2bee54n%40googlegroups.com.

Re: [go-nuts] Error handling

['Luke Crook' via golang-nuts]

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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com.

Re: [go-nuts] Error handling

['Luke Crook' via golang-nuts]

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 were not nil.
>

Some of my thoughts.I can see a developer (using myself as an example)
assuming this will work in the generalized case of any non-nil return value
(not just of type error). "orelse" doesn't really convey the intent of
restricting this conditional only to the handling of errors.

What would happen if the error is ignored?

```
count, _ := io.Copy(w, r) *orelse* {
DoSomethingElse()
}
```

And does anyone besides me write code like this?

```
result, err := makeSomeNoise(); err != nil && result > 0 {
DoSomethingElse()
}
```

Would this become,

```
result, err := makeSomeNoise() orelse if result > 0 {
DoSomethingElse()
}
```

or,

```
result, err := makeSomeNoise() orelse {
   if result > 0 {
  DoSomethingElse()
   }
}
```



On Tuesday, August 1, 2023 at 1:36:04 AM UTC-6 Marcello H wrote:
>
>> 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.
>>
>> ```
>> result, err := makeSomeNoise() *orelse* {
>> DoSomethingElse()
>> }
>> ```
>> vs
>> ```
>> result, err := makeSomeNoise() if err != nil {
>> DoSomethingElse()
>> }
>> ```
>> Ehm, this saves 16-9 = 7 keyboard entries.
>> If you ask me, this still reads consistent with the "normal" way we
>> handle errors.
>>
>> What happens if all of a sudden, the makeSomeNoise returns 2 errors? Then
>> you have to undo the orelse construction, for what I understand.
>>
>> The more I think of this, the more I like to type those extra keyboard
>> entries  to have a clear look about what happens in the program.
>>
>> Just my 2 cents
>>
>>
>>
>>
>> Op di 1 aug 2023 om 03:31 schreef robert engels :
>>
>>> 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 designers do not want exceptions in any way shape or form, so
>>> you’re pretty much going to be stuck with what you have (all of the decent
>>> proposals are “exception like”- exceptions by another name) so learn to
>>> love it or use a different language.
>>>
>>> On Jul 30, 2023, at 2:02 AM, Brian Candler  wrote:
>>>
>>> Just to be clear: are you hard-coding the variable name "err" into the
>>> semantics of "orelse"?  That is, you can't assign the error return to a
>>> variable of any other name?
>>>
>>> I disagree that this makes the job of linters any easier than it is
>>> today.  For example, if you'd written
>>>
>>> ...
>>>err = io.Copy(w, r)
>>> err = w.Close() orelse return err
>>> }
>>>
>>> then you'd still need to detect "value assigned but not used" in the
>>> linter (assuming it doesn't become *compulsory* to use "orelse" on any
>>> assignment to a variable called "err")
>>>
>>> On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote:
>>>
 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 syntactic
 sugar for an "if err!=nil" block.

 The example code in Russ Cox's paper[1] will look something like this:

 func CopyFile(src, dst string) error {
 r, err := os.Open(src) orelse return err
 defer r.Close()
 w, err := os.Create(dst) orelse return err
 defer w.Close()
   err = io.Copy(w, r) orelse return err
 err = w.Close() orelse return err
 }

 It is an error to not return an error from an orelse block.

 In my eyes, this has the same explicitness and flexibility of the
 current style but is significantly less verbose. It permits ignoring the
 error, returning it as is or wrapping it. Because orelse is not used for
 any other purpose, it would be easy for reviewers and linters to spot lack
 of error handling.

 It also works well with named returns. e.g.,

 func returnsObjorErro() (obj Obj, err error) {
   obj, err := createObj() orelse return  //returns nil and err
 }

 otherwise orelse is like "else" so e.g., it can be followed by a block
 if additional cleanup or error formatting etc is needed before returning,
 eg
 w, err := os.Create(dst) orel

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

[announce]

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 keys in certificate chains can cause a client/server
to expend significant CPU time verifying signatures. Limit this by
restricting the size of RSA keys transmitted during handshakes to <=
8192 bits.

Based on a survey of publicly trusted RSA keys, there are currently only
three certificates in circulation with keys larger than this, and all
three appear to be test certificates that are not actively deployed. It
is possible there are larger keys in use in private PKIs, but we target
the web PKI, so causing breakage here in the interests of increasing the
default safety of users of crypto/tls seems reasonable.

Thanks to Mateusz Poliwczak for reporting this issue.

View the release notes for more information:
https://go.dev/doc/devel/release#go1.20.7

You can download binary and source distributions from the Go website:
https://go.dev/dl/

To compile from source using a Git clone, update to the release with
git checkout go1.20.7 and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Matthew for the Go team

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/-L4OUCDMTzmUZY9glU7dGA%40geopod-ismtpd-10.

Re: [go-nuts] Error handling

[Victor Giordano]

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 do understand that
some folks provide some push back on the idea simply because there is
nothing wrong with the language right now regarding error handling.

As I see things, the language was simple in their origins, but from time to
time they complicated a little more some things, for example "what about
generics?"  (are they really necessary?, I mean... I think using interfaces
provides all the genericity you may need). So I guess there is room to make
some changes and make the language easier. I would say that both ways of
handling errors are valid, the most important is to be as simple
as possible so you ensure that other people understand it. Like Generics,
you don't have to use them. So I would praise it for adding another way,
less repetitive.

Also like to see how people react and what their opinions are. So far what
I read is just personal taste.


El mar, 1 ago 2023 a las 16:04, 'Luke Crook' via golang-nuts (<
golang-nuts@googlegroups.com>) escribió:

> And of course I forgot the "if" at the beginning of all those conditional.
> *sigh*
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/dRLR4hxxI8A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com
> 
> .
>


-- 
V

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPUu9ss4ToLJUHr8yAXHOLUjLWShB4-oKmOMD3_bzsAf7ohxvA%40mail.gmail.com.

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

[Jochen Voss]

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 coverage: 0/2 completed
fuzz: elapsed: 0s, gathering baseline coverage: 2/2 completed, now fuzzing 
with 10 workers
fuzz: elapsed: 3s, execs: 280461 (93481/sec), new interesting: 24 (total: 
26)
fuzz: elapsed: 5s, execs: 410320 (72348/sec), new interesting: 60 (total: 
62)
--- FAIL: FuzzToUnicode (4.80s)
--- FAIL: FuzzToUnicode (0.00s)
tounicode_test.go:129: template: tounicode:26:2: executing 
"tounicode" at : error calling Single: runtime error: integer 
divide by zero

Failing input written to testdata/fuzz/FuzzToUnicode/2566873a28045c1b
To re-run:
go test -run=FuzzToUnicode/2566873a28045c1b
FAIL
exit status 1
FAIL seehuhn.de/go/pdf/font/tounicode2 4.957s
voss@dumpling [..nt/tounicode2] go test -run=FuzzToUnicode/2566873a28045c1b
PASS
ok   seehuhn.de/go/pdf/font/tounicode2 0.122s

The fuzzer reported a failure, and when I re-run the test I get a "PASS".

How to debug such a problem?

I understand that my fuzz function may somehow be non-deterministic, but so 
far I have not found any cause of non-determinism and re-running the test 
10 times gives me 10 passes.  Also, for a bug the fuzzer reported earlier, 
I found it very hard to believe that the given input could make the fuzz 
function reach the site of the error message.  Could it be that the fuzzer 
sometimes looses track of which input belongs to which fuzzing run, and 
then reports the wrong input?

If somebody wants to play with this, here is how to reproduce (up to 
randomness) the fuzzing run shown above:

 git clone https://github.com/seehuhn/go-pdf.git
 cd go-pdf/
 git reset --hard 26c235ad
 cd font/tounicode2/
 go test -fuzz FuzzToUnicode

Any suggestions on how to debug such errors would be most welcome.

Many thanks,
Jochen

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3fe3725b-e59e-4b1f-a2e9-0f28c15ea3d4n%40googlegroups.com.

Re: [go-nuts] Error handling

[Brian Candler]

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 people would ask "why not pointers? why not channels?" 
etc.  I'm not suggesting it should become like Python where every non-zero 
value is treated as "true".  Interface values are special, and there's very 
little you can do with a nil interface (whereas for example, a nil pointer 
can still have methods called on it).  But this does add a special case, 
and Go already has its share of surprises you have to learn.

On Tuesday, 1 August 2023 at 22:41:38 UTC+1 DrGo wrote:

> Yes. Go is no longer the simple language it was. I suspect because of 
> internal pressures within Google as evidenced by multiple innovations that 
> seem to come from nowhere eg dir embedding and associated fs package that 
> duplicated perfectly good ways of doing things. The module system while 
> useful is quite complex. Generics and all the associated packages inflated 
> the mental burden of learning and reading Go code significantly. And having 
> the go 1 compatibility guarantee means that old stuff remains valid code 
> and must be learned too. 
>
> On Tuesday, August 1, 2023 at 2:59:07 PM UTC-6 Victor Giordano wrote:
>
>> 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 do understand that 
>> some folks provide some push back on the idea simply because there is 
>> nothing wrong with the language right now regarding error handling. 
>>
>> As I see things, the language was simple in their origins, but from time 
>> to time they complicated a little more some things, for example "what about 
>> generics?"  (are they really necessary?, I mean... I think using interfaces 
>> provides all the genericity you may need). So I guess there is room to make 
>> some changes and make the language easier. I would say that both ways of 
>> handling errors are valid, the most important is to be as simple 
>> as possible so you ensure that other people understand it. Like Generics, 
>> you don't have to use them. So I would praise it for adding another way, 
>> less repetitive.
>>
>> Also like to see how people react and what their opinions are. So far 
>> what I read is just personal taste.
>>
>>
>> El mar, 1 ago 2023 a las 16:04, 'Luke Crook' via golang-nuts (<
>> golan...@googlegroups.com>) escribió:
>>
>>> And of course I forgot the "if" at the beginning of all those 
>>> conditional. *sigh*
>>>
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/golang-nuts/dRLR4hxxI8A/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> golang-nuts...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> V
>>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/11d57ab3-e7d8-4636-8ef7-6de64404bc54n%40googlegroups.com.