Re: [go-nuts] Error handling

[DrGo]

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

> 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 off 
> gofmt and write `; if err !=nil {; return err }`
>
> I'd like to point out that considering 
>
> > It is an error to not return an error from an orelse block.
>
> The `return err` in examples still is a boilerplate, so the overall 
> savings are just four utf-8 bytes, ie. {\n}\n.
>
> I understand sentiment, 'cos there is a huge camp of devs claiming that 
> any error handling proper is one that is done by something/someone up the 
> callstack, even future-me — for this camp idiomatic Go can be annoying.
>
> But note that for the most pleasant coder experience the `orelse return 
> err` is way too much of text to write. 
>
> I would better stay with ^^ digraph instead. Lets name it a 'bat operator'.
>
> func CopyFile(src, dst string) error { 
> r, err := os.Open(src) ^^ 
> defer r.Close()
> w, err := os.Create(dst) ^^
> defer w.Close()
> err = io.Copy(w, r) ^^
> err = w.Close() ^^
> }
>
> > It also works well with named returns. e.g., 
>
> func returnsObjorErro() (obj Obj, err error) {
> obj, err := createObj() ^^ //returns nil and err
> } 
>
> > otherwise ^^ 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) ^^ {
> 
> return err 
> }
>
> P.S — bat operator is easily implementable in an IDE with 
> onFileOpen/onFileWrite hooks.
> Its the piping of content to tools (VSCode and GoLand) that bars me from 
> personally using it.
>
> Hope this helps,
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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/dfa8041e-7e16-4ef5-a97b-a7282ba6b5c4n%40googlegroups.com.

Re: [go-nuts] Error handling

[DrGo]

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 
> 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 
> productive to those types of devs and/or types of Go modules, that is, 
> applications.
>
> On Wednesday, August 2, 2023 at 9:27:23 PM UTC+2 TheDiveO wrote:
>
>>
>> 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 package writer that will be used in 
>>larger contexts: "[Go's error handling is] *simple and explicit [...] 
>>It's not a big deal when writing production code, because then you want 
>>more control over error handling anyway -- nicely-wrapped errors, or 
>>human-readable messages [...]*"
>>2. from a "script" developer perspective, where "*all the error 
>>handling you need is to show a message, print a stack trace, and exit the 
>>program*".
>>
>> There might be more angles to it, but Ben's sentiment rings a bell with 
>> my own "customer" experience.
>>
>> So we can at least expect to have two "camps of judges" when it comes to 
>> error handling improvement proposals. Some of the judges might be acutely 
>> aware of the at least two different angles, but some of the comments not 
>> least in this thread ("language designers" as kind of gods who must ignore 
>> their customers, seriously?) seem to indicate that this isn't always the 
>> case. Not least, I also fall into the less desirable category of the 
>> ignoramus.
>>
>> So, maybe we should in the future always ask when it comes to a proposal: 
>> which of the two perspectives does the proposal tackle? I'm under the 
>> assumption that it might have been #2 in most of the proposals. The often 
>> vivid negative responses should then be classified as belonging to #1 
>> and/or #2. If the proposal is about #2, then #1 proponents don't 
>> contribute, but simply make life hard for the #2 customers of the Go 
>> language. Same for the opposite combination.
>>
>> On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote:
>>
>>> 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 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 

Re: [go-nuts] Error handling

[DrGo]

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 perfectly 
acceptable to have two ways to do something; and I argue that something as 
important and fundemental as error handling is one of those things. Your 
explanation above demonstrates the case.


 

On Wednesday, August 2, 2023 at 1:27:23 PM UTC-6 TheDiveO wrote:

>
> 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 package writer that will be used in 
>larger contexts: "[Go's error handling is] *simple and explicit [...] 
>It's not a big deal when writing production code, because then you want 
>more control over error handling anyway -- nicely-wrapped errors, or 
>human-readable messages [...]*"
>2. from a "script" developer perspective, where "*all the error 
>handling you need is to show a message, print a stack trace, and exit the 
>program*".
>
> There might be more angles to it, but Ben's sentiment rings a bell with my 
> own "customer" experience.
>
> So we can at least expect to have two "camps of judges" when it comes to 
> error handling improvement proposals. Some of the judges might be acutely 
> aware of the at least two different angles, but some of the comments not 
> least in this thread ("language designers" as kind of gods who must ignore 
> their customers, seriously?) seem to indicate that this isn't always the 
> case. Not least, I also fall into the less desirable category of the 
> ignoramus.
>
> So, maybe we should in the future always ask when it comes to a proposal: 
> which of the two perspectives does the proposal tackle? I'm under the 
> assumption that it might have been #2 in most of the proposals. The often 
> vivid negative responses should then be classified as belonging to #1 
> and/or #2. If the proposal is about #2, then #1 proponents don't 
> contribute, but simply make life hard for the #2 customers of the Go 
> language. Same for the opposite combination.
>
> On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote:
>
>> 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 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 
> 

Re: [go-nuts] Error handling

[Wojciech S. Czarnecki]

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 off gofmt 
and write `; if err !=nil {; return err }`

I'd like to point out that considering 

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

The `return err` in examples still is a boilerplate, so the overall savings are 
just four utf-8 bytes, ie. {\n}\n.

I understand sentiment, 'cos there is a huge camp of devs claiming that any 
error handling proper is one that is done by something/someone up the 
callstack, even future-me — for this camp idiomatic Go can be annoying.

But note that for the most pleasant coder experience the `orelse return err` is 
way too much of text to write. 

I would better stay with ^^ digraph instead.  Lets name it a 'bat operator'.

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

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

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

> otherwise ^^ 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) ^^ {
   
  return err 
}

P.S — bat operator is easily implementable in an IDE with 
onFileOpen/onFileWrite hooks.
Its the piping of content to tools (VSCode and GoLand) that bars me from 
personally using it.

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20230802225759.198a4de2%40xmint.

Re: [go-nuts] Error handling

[TheDiveO]

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 
productive to those types of devs and/or types of Go modules, that is, 
applications.

On Wednesday, August 2, 2023 at 9:27:23 PM UTC+2 TheDiveO wrote:

>
> 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 package writer that will be used in 
>larger contexts: "[Go's error handling is] *simple and explicit [...] 
>It's not a big deal when writing production code, because then you want 
>more control over error handling anyway -- nicely-wrapped errors, or 
>human-readable messages [...]*"
>2. from a "script" developer perspective, where "*all the error 
>handling you need is to show a message, print a stack trace, and exit the 
>program*".
>
> There might be more angles to it, but Ben's sentiment rings a bell with my 
> own "customer" experience.
>
> So we can at least expect to have two "camps of judges" when it comes to 
> error handling improvement proposals. Some of the judges might be acutely 
> aware of the at least two different angles, but some of the comments not 
> least in this thread ("language designers" as kind of gods who must ignore 
> their customers, seriously?) seem to indicate that this isn't always the 
> case. Not least, I also fall into the less desirable category of the 
> ignoramus.
>
> So, maybe we should in the future always ask when it comes to a proposal: 
> which of the two perspectives does the proposal tackle? I'm under the 
> assumption that it might have been #2 in most of the proposals. The often 
> vivid negative responses should then be classified as belonging to #1 
> and/or #2. If the proposal is about #2, then #1 proponents don't 
> contribute, but simply make life hard for the #2 customers of the Go 
> language. Same for the opposite combination.
>
> On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote:
>
>> 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 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, 

Re: [go-nuts] Error handling

[TheDiveO]

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 package writer that will be used in 
   larger contexts: "[Go's error handling is] *simple and explicit [...] 
   It's not a big deal when writing production code, because then you want 
   more control over error handling anyway -- nicely-wrapped errors, or 
   human-readable messages [...]*"
   2. from a "script" developer perspective, where "*all the error handling 
   you need is to show a message, print a stack trace, and exit the program*
   ".

There might be more angles to it, but Ben's sentiment rings a bell with my 
own "customer" experience.

So we can at least expect to have two "camps of judges" when it comes to 
error handling improvement proposals. Some of the judges might be acutely 
aware of the at least two different angles, but some of the comments not 
least in this thread ("language designers" as kind of gods who must ignore 
their customers, seriously?) seem to indicate that this isn't always the 
case. Not least, I also fall into the less desirable category of the 
ignoramus.

So, maybe we should in the future always ask when it comes to a proposal: 
which of the two perspectives does the proposal tackle? I'm under the 
assumption that it might have been #2 in most of the proposals. The often 
vivid negative responses should then be classified as belonging to #1 
and/or #2. If the proposal is about #2, then #1 proponents don't 
contribute, but simply make life hard for the #2 customers of the Go 
language. Same for the opposite combination.

On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote:

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

Re: [go-nuts] Error handling

[DrGo]

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 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/7f7c62e4-805f-46ef-8b77-64e5fe3b3cdfn%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.

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.

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) 

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

[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 you 

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

[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 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/60596671-D3AC-49D4-8575-F8EB3D9B6BF6%40ix.netcom.com.

Re: [go-nuts] error handling thoughts

[Ian Lance Taylor]

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 pointed out, the compiler does not give such an error.
The error must be coming from some other tool.  If you tell us what
tool that is, perhaps we can fix it.  In general a tool should not
recommend removing the else clause from an if statement with a simple
statement that declares variables if the else clause refers to any of
those variables.

Ian

-- 
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/CAOyqgcUSEXDinAw_cHEE-SJ8z-feAC2LPwXZESVe03tmFfMYbw%40mail.gmail.com.

Re: [go-nuts] Error Handling

[ben...@gmail.com]

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 
errHandle(), *if it's at the top level in main*. I often have a function 
like this in main.go for CLIs. The signature might be:

inFile, err := os.ReadFile("Mydata.txt")
exitOnError(err, "cannot read file")

-Ben

On Wednesday, February 8, 2023 at 11:01:53 AM UTC+13 Richard Masci wrote:

> 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 `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 10:39 PM Rich  wrote:
>>
>>> 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 := os.ReadFile("Mydata.txt")
>>> errorHandle(err,"read mydata.txt",true) // The true will exit
>>>
>>> So you see that I can exit the program when there is an error, what I 
>>> want to know is if it's possible to do the same thing inside a function, to 
>>> where I don't exit the program but return from the function:
>>>
>>> func OpenFile( filename string) []byte {
>>> inFile,err := os.ReadFile(filename)
>>> errReturn(err, "read "+filname,true)
>>>
>>> When there is an error it would return from the OpenFile function,
>>>
>>> -- 
>>> 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/2eec0130-3deb-4f60-a13e-d7c9d132771dn%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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/c77b336e-85a8-4e3e-a64d-e5e3f1759c68n%40googlegroups.com.

Re: [go-nuts] Error Handling

[Richard Masci]

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 `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 10:39 PM Rich  wrote:
>
>> 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 := os.ReadFile("Mydata.txt")
>> errorHandle(err,"read mydata.txt",true) // The true will exit
>>
>> So you see that I can exit the program when there is an error, what I
>> want to know is if it's possible to do the same thing inside a function, to
>> where I don't exit the program but return from the function:
>>
>> func OpenFile( filename string) []byte {
>> inFile,err := os.ReadFile(filename)
>> errReturn(err, "read "+filname,true)
>>
>> When there is an error it would return from the OpenFile function,
>>
>> --
>> 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/2eec0130-3deb-4f60-a13e-d7c9d132771dn%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CAJ0CmuGaHPF9ZZpHZf2G8N7eY_NM8%3DpE9z6vGp8tYvEnv6vbnQ%40mail.gmail.com.

Re: [go-nuts] Error Handling

['Axel Wagner' via golang-nuts]

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 10:39 PM Rich  wrote:

> 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 := os.ReadFile("Mydata.txt")
> errorHandle(err,"read mydata.txt",true) // The true will exit
>
> So you see that I can exit the program when there is an error, what I want
> to know is if it's possible to do the same thing inside a function, to
> where I don't exit the program but return from the function:
>
> func OpenFile( filename string) []byte {
> inFile,err := os.ReadFile(filename)
> errReturn(err, "read "+filname,true)
>
> When there is an error it would return from the OpenFile function,
>
> --
> 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/2eec0130-3deb-4f60-a13e-d7c9d132771dn%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfHgrMYVNCzbTtf5%3De8qDwyarbH44GvdXieFSKq502ChtQ%40mail.gmail.com.

Re: [go-nuts] Error Handling Question

[Bakul Shah]

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)
> }
> limit, err := Limit()
> if err != nil {
> return fmt.Errorf("enforcing foo limit: %w", err)
> }
> if foo > limit {
> foo, err = DiminishFoo(foo)
> if err != nil {
> return fmt.Errorf("enforcing foo limit: %v", err)
> }
> if foo > limit {
> return fmt.Errorf("foo value %d exceeds limit %d, even after 
> diminishment", foo, limit)
> }
> }

Some languages have optional types so for example you can do

foo := Foo() or { return fmt.Error("enforcing foo limit: %w", err) }
limit := Limit() or { return fmt.Errorf("enforcing foo limit: %w", err) }
if foo > limit {
...
}

If you just want to punt the error to the caller, you do

foo := Foo()?
limit := Limit()?

etc. Now this is just syntactic sugar and semantically almost
identical to what Go does. Except that err becomes a builtin.
Making it a builtin can potentially be useful as the compiler
can embed information such as which line or expression generated
the error (or passed it on) for debugging.

A function returning such a value may be declared as

fn Foo() ?typeFoo {
var foo typeFoo
...
return foo
...
return err...
}

I find this easier to read as the error handling code doesn't
overwhelm the non-error logic and the compiler can check if a
Foo() caller doesn't handle the error case and print a message.
And I find this much less odious than try ... catch ... +
compilers can't easily check if exceptions are indeed handled
without adding more boilerplate code.

Though I don't think Go authors like this style. 

-- 
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/03295133-85E2-4358-8910-E95612C026BF%40iitbombay.org.

Re: [go-nuts] Error Handling Question

['Daniel Lepage' via golang-nuts]

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 treated as such, which
> means that the calling function should be able to decide what to do, and
> this should include continuing. Frequently it won't - a lot of error
> handling is just return fmt.Errorf("more context %w", err) - but any
> proposal that assumes that it *always* won't is, IMO, confusing errors with
> panics. This is the question that first started this thread - I didn't
> understand why all the existing error proposals explicitly required that a
> function terminate when it encounters an error, and AFAICT the answer is
> "because people are used to thinking of errors more like panics than like
> return values".
>
> For what it's worth, I see this differently.  The existing language is
> not going to go away, and it's pretty good at handling the cases where
> an error occurs and the function does not return.  Those cases are by
> their nature all distinct.  They are not boilerplate.  The way we
> write them today is fine: easy to read and not too hard to write.
> When people writing Go complain about error handling, what they are
> complaining about is the repetitive boilerplate, particularly "if err
> != nil { return nil, err }".  If we make any substantive changes to
> the language or standard library for better error handling, that is
> what we should address.  If we can address other cases, fine, but as
> they already work OK they should not be the focus of any substantive
> change.


Ok, that makes sense, and I think answers my initial question - all recent
error-handling proposals have been termination-based not because anyone is
specifically *against* streamlining continuation cases, just because it's
also not important to anyone.

> Is part of the problem that the discussion around the
> try/check/handle/etc. proposals got so involved that nobody wants to even
> consider anything that looks too similar to those? Would it be more
> palatable if I proposed it with names that made it clearer that this is
> about the consolidation of error handling rather than an attempt to replace
> it entirely?
> >
> > onErrors {
> > if must Foo(must Bar(), must Baz()) > 1 {
> >   ...
> >}
> > } on err {
> >...
> > }
>
> While error handling is important, the non-error code path is more
> important.  Somebody reading a function should be able to easily and
> naturally focus on the non-error code.  That works moderately well
> today, as the style is "if err != nil { ... }" where the "..." is
> indented out of the normal flow.  It's fairly easy for the reader to
> skip over the error handling code in order to focus on the non-error
> code.  A syntactic construct such as you've written above buries the
> lede: what you see first is the error path, but in many cases you
> actually want to focus on the non-error path.
>

Sorry, "onErrors" was a poor choice of word to replace 'try'; I wasn't
proposing putting the handling before the non-error code, just wondering if
using different names for try/check/handle would help. Using my original
proposal but with must/on instead of check/handle, code would look like
this:

try {
if foo, limit := must Foo(), must Limit(); foo > limit {
if foo = must DiminishFoo(foo); foo > limit {
return fmt.Errorf("foo value %d exceeds limit %d, even after
diminishment", foo, limit)
  }
  }
} on err {
  return fmt.Errorf("enforcing foo limit: %w", err)
}

You can read the normal flow pretty easily here - you compute a value and a
limit, and if the value exceeds the limit you try to reduce it, and if it
still exceeds the limit you return an error. Foo(), Limit(), and
DiminishFoo() all return (value, error) pairs, but we don't consider this
part of the "normal" control flow, so the code that handles if any of them
fail is separated into its own block slightly further down.

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)
}
limit, err := Limit()
if err != nil {
return fmt.Errorf("enforcing foo limit: %w", err)
}
if foo > limit {
foo, err = DiminishFoo(foo)
if err != nil {
return fmt.Errorf("enforcing foo limit: %v", err)
}
if foo > limit {
return fmt.Errorf("foo value %d exceeds limit %d, even after
diminishment", foo, limit)
}
}

This is fundamentally what I'm trying to propose - I'm not trying to
address the existence of boilerplate, just trying to make it easier to move
identical error handling blocks to the end so that the normal flow is more
visible.

I have no idea if "must" is better than "check" - it's maybe clearer that
it's going to jump to 

Re: [go-nuts] Error Handling Question

[Ian Lance Taylor]

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 hardly seems worth the effort. Great engineering is built by
> standing on the shoulders of giants. I haven’t seen any arguments that
> refute their findings.
>

I'm not sure that the problem that you see is a problem that we are
interested in solving.  Go is not Java, nor should it be.  We already have
Java, and it's a fine language.

In any case it's been years since the Go team has made any proposals
related to error handing.

Ian



On Oct 24, 2022, at 10:52 PM, Ian Lance Taylor  wrote:
>
> 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 != nil {
>  return err
> }
>
> boilerplate. This is exactly what checked exceptions are designed to
> address.
>
> Sure, it you don’t properly decompose your functions the Go error handling
> makes this safer, but properly decompose the functions and checked
> exceptions make things far far easier.
>
>
> Thanks, but this has been discussed at great length in the past.  We
> don't need to rehash yet again.
>
> Ian
>
>
>
> On Oct 24, 2022, at 10:28 PM, Ian Lance Taylor  wrote:
>
> 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 , out of disk space.  If the code is properly decomposed that
> function can’t handle it - so it throws - and hopefully a higher level
> function is able to cope (by handling the specific exception) - maybe
> asking the user for a different file name or a different destination device.
>
> And the writing function can easily cleanup any temp state due to the
> stack unwinding and AutoClosable, etc.
>
>
> I did not mean to imply that that was the only consideration for error
> handling.
>
> Go style is to avoid exceptions for other reasons
> (https://go.dev/doc/faq#exceptions).
>
> Ian
>
>
> On Oct 24, 2022, at 6: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 treated as such, which
> means that the calling function should be able to decide what to do, and
> this should include continuing. Frequently it won't - a lot of error
> handling is just return fmt.Errorf("more context %w", err) - but any
> proposal that assumes that it *always* won't is, IMO, confusing errors with
> panics. This is the question that first started this thread - I didn't
> understand why all the existing error proposals explicitly required that a
> function terminate when it encounters an error, and AFAICT the answer is
> "because people are used to thinking of errors more like panics than like
> return values".
>
>
> For what it's worth, I see this differently.  The existing language is
> not going to go away, and it's pretty good at handling the cases where
> an error occurs and the function does not return.  Those cases are by
> their nature all distinct.  They are not boilerplate.  The way we
> write them today is fine: easy to read and not too hard to write.
> When people writing Go complain about error handling, what they are
> complaining about is the repetitive boilerplate, particularly "if err
> != nil { return nil, err }".  If we make any substantive changes to
> the language or standard library for better error handling, that is
> what we should address.  If we can address other cases, fine, but as
> they already work OK they should not be the focus of any substantive
> change.
>
>
> Is part of the problem that the discussion around the
> try/check/handle/etc. proposals got so involved that nobody wants to even
> consider anything that looks too similar to those? Would it be more
> palatable if I proposed it with names that made it clearer that this is
> about the consolidation of error handling rather than an attempt to replace
> it entirely?
>
> onErrors {
>  if must Foo(must Bar(), must Baz()) > 1 {
>...
> }
> } on err {
> ...
> }
>
>
> While error handling is important, the non-error code path is more
> important.  Somebody reading a function should be able to easily and
> naturally focus on the non-error code.  That works moderately well
> today, as the style is "if err != nil { ... }" where the "..." is
> indented out of the normal flow.  It's fairly easy for 

Re: [go-nuts] Error Handling Question

[robert engels]

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 standing on 
the shoulders of giants. I haven’t seen any arguments that refute their 
findings.

> On Oct 24, 2022, at 10:52 PM, Ian Lance Taylor  wrote:
> 
> 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 != nil {
>>  return err
>> }
>> 
>> boilerplate. This is exactly what checked exceptions are designed to address.
>> 
>> Sure, it you don’t properly decompose your functions the Go error handling 
>> makes this safer, but properly decompose the functions and checked 
>> exceptions make things far far easier.
> 
> Thanks, but this has been discussed at great length in the past.  We
> don't need to rehash yet again.
> 
> Ian
> 
> 
> 
>>> On Oct 24, 2022, at 10:28 PM, Ian Lance Taylor  wrote:
>>> 
>>> 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 , out of disk space.  If the code is properly decomposed 
 that function can’t handle it - so it throws - and hopefully a higher 
 level function is able to cope (by handling the specific exception) - 
 maybe asking the user for a different file name or a different destination 
 device.
 
 And the writing function can easily cleanup any temp state due to the 
 stack unwinding and AutoClosable, etc.
>>> 
>>> I did not mean to imply that that was the only consideration for error 
>>> handling.
>>> 
>>> Go style is to avoid exceptions for other reasons
>>> (https://go.dev/doc/faq#exceptions).
>>> 
>>> Ian
>>> 
>>> 
>> On Oct 24, 2022, at 6: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 treated as such, which 
>> means that the calling function should be able to decide what to do, and 
>> this should include continuing. Frequently it won't - a lot of error 
>> handling is just return fmt.Errorf("more context %w", err) - but any 
>> proposal that assumes that it *always* won't is, IMO, confusing errors 
>> with panics. This is the question that first started this thread - I 
>> didn't understand why all the existing error proposals explicitly 
>> required that a function terminate when it encounters an error, and 
>> AFAICT the answer is "because people are used to thinking of errors more 
>> like panics than like return values".
> 
> For what it's worth, I see this differently.  The existing language is
> not going to go away, and it's pretty good at handling the cases where
> an error occurs and the function does not return.  Those cases are by
> their nature all distinct.  They are not boilerplate.  The way we
> write them today is fine: easy to read and not too hard to write.
> When people writing Go complain about error handling, what they are
> complaining about is the repetitive boilerplate, particularly "if err
> != nil { return nil, err }".  If we make any substantive changes to
> the language or standard library for better error handling, that is
> what we should address.  If we can address other cases, fine, but as
> they already work OK they should not be the focus of any substantive
> change.
> 
> 
>> Is part of the problem that the discussion around the 
>> try/check/handle/etc. proposals got so involved that nobody wants to 
>> even consider anything that looks too similar to those? Would it be more 
>> palatable if I proposed it with names that made it clearer that this is 
>> about the consolidation of error handling rather than an attempt to 
>> replace it entirely?
>> 
>> onErrors {
>>  if must Foo(must Bar(), must Baz()) > 1 {
>>...
>> }
>> } on err {
>> ...
>> }
> 
> While error handling is important, the non-error code path is more
> important.  Somebody reading a function should be able to easily and
> naturally focus on the non-error code.  That works moderately well
> today, as the style is "if err != nil { ... }" where the "..." 

Re: [go-nuts] Error Handling Question

[Ian Lance Taylor]

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 != nil {
>   return err
> }
>
> boilerplate. This is exactly what checked exceptions are designed to address.
>
> Sure, it you don’t properly decompose your functions the Go error handling 
> makes this safer, but properly decompose the functions and checked exceptions 
> make things far far easier.

Thanks, but this has been discussed at great length in the past.  We
don't need to rehash yet again.

Ian



> > On Oct 24, 2022, at 10:28 PM, Ian Lance Taylor  wrote:
> >
> > 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 , out of disk space.  If the code is properly decomposed 
> >> that function can’t handle it - so it throws - and hopefully a higher 
> >> level function is able to cope (by handling the specific exception) - 
> >> maybe asking the user for a different file name or a different destination 
> >> device.
> >>
> >> And the writing function can easily cleanup any temp state due to the 
> >> stack unwinding and AutoClosable, etc.
> >
> > I did not mean to imply that that was the only consideration for error 
> > handling.
> >
> > Go style is to avoid exceptions for other reasons
> > (https://go.dev/doc/faq#exceptions).
> >
> > Ian
> >
> >
>  On Oct 24, 2022, at 6: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 treated as such, which 
>  means that the calling function should be able to decide what to do, and 
>  this should include continuing. Frequently it won't - a lot of error 
>  handling is just return fmt.Errorf("more context %w", err) - but any 
>  proposal that assumes that it *always* won't is, IMO, confusing errors 
>  with panics. This is the question that first started this thread - I 
>  didn't understand why all the existing error proposals explicitly 
>  required that a function terminate when it encounters an error, and 
>  AFAICT the answer is "because people are used to thinking of errors more 
>  like panics than like return values".
> >>>
> >>> For what it's worth, I see this differently.  The existing language is
> >>> not going to go away, and it's pretty good at handling the cases where
> >>> an error occurs and the function does not return.  Those cases are by
> >>> their nature all distinct.  They are not boilerplate.  The way we
> >>> write them today is fine: easy to read and not too hard to write.
> >>> When people writing Go complain about error handling, what they are
> >>> complaining about is the repetitive boilerplate, particularly "if err
> >>> != nil { return nil, err }".  If we make any substantive changes to
> >>> the language or standard library for better error handling, that is
> >>> what we should address.  If we can address other cases, fine, but as
> >>> they already work OK they should not be the focus of any substantive
> >>> change.
> >>>
> >>>
>  Is part of the problem that the discussion around the 
>  try/check/handle/etc. proposals got so involved that nobody wants to 
>  even consider anything that looks too similar to those? Would it be more 
>  palatable if I proposed it with names that made it clearer that this is 
>  about the consolidation of error handling rather than an attempt to 
>  replace it entirely?
> 
>  onErrors {
>    if must Foo(must Bar(), must Baz()) > 1 {
>  ...
>   }
>  } on err {
>   ...
>  }
> >>>
> >>> While error handling is important, the non-error code path is more
> >>> important.  Somebody reading a function should be able to easily and
> >>> naturally focus on the non-error code.  That works moderately well
> >>> today, as the style is "if err != nil { ... }" where the "..." is
> >>> indented out of the normal flow.  It's fairly easy for the reader to
> >>> skip over the error handling code in order to focus on the non-error
> >>> code.  A syntactic construct such as you've written above buries the
> >>> lede: what you see first is the error path, but in many cases you
> >>> actually want to focus on the non-error path.
> >>>
> >>> Ian
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups 
> >>> "golang-nuts" group.
> >>> To unsubscribe from this group and 

Re: [go-nuts] Error Handling Question

[Robert Engels]

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 checked exceptions are designed to address. 

Sure, it you don’t properly decompose your functions the Go error handling 
makes this safer, but properly decompose the functions and checked exceptions 
make things far far easier. 

> On Oct 24, 2022, at 10:28 PM, Ian Lance Taylor  wrote:
> 
> 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 , out of disk space.  If the code is properly decomposed that function 
>> can’t handle it - so it throws - and hopefully a higher level function is 
>> able to cope (by handling the specific exception) - maybe asking the user 
>> for a different file name or a different destination device.
>> 
>> And the writing function can easily cleanup any temp state due to the stack 
>> unwinding and AutoClosable, etc.
> 
> I did not mean to imply that that was the only consideration for error 
> handling.
> 
> Go style is to avoid exceptions for other reasons
> (https://go.dev/doc/faq#exceptions).
> 
> Ian
> 
> 
 On Oct 24, 2022, at 6: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 treated as such, which 
 means that the calling function should be able to decide what to do, and 
 this should include continuing. Frequently it won't - a lot of error 
 handling is just return fmt.Errorf("more context %w", err) - but any 
 proposal that assumes that it *always* won't is, IMO, confusing errors 
 with panics. This is the question that first started this thread - I 
 didn't understand why all the existing error proposals explicitly required 
 that a function terminate when it encounters an error, and AFAICT the 
 answer is "because people are used to thinking of errors more like panics 
 than like return values".
>>> 
>>> For what it's worth, I see this differently.  The existing language is
>>> not going to go away, and it's pretty good at handling the cases where
>>> an error occurs and the function does not return.  Those cases are by
>>> their nature all distinct.  They are not boilerplate.  The way we
>>> write them today is fine: easy to read and not too hard to write.
>>> When people writing Go complain about error handling, what they are
>>> complaining about is the repetitive boilerplate, particularly "if err
>>> != nil { return nil, err }".  If we make any substantive changes to
>>> the language or standard library for better error handling, that is
>>> what we should address.  If we can address other cases, fine, but as
>>> they already work OK they should not be the focus of any substantive
>>> change.
>>> 
>>> 
 Is part of the problem that the discussion around the 
 try/check/handle/etc. proposals got so involved that nobody wants to even 
 consider anything that looks too similar to those? Would it be more 
 palatable if I proposed it with names that made it clearer that this is 
 about the consolidation of error handling rather than an attempt to 
 replace it entirely?
 
 onErrors {
   if must Foo(must Bar(), must Baz()) > 1 {
 ...
  }
 } on err {
  ...
 }
>>> 
>>> While error handling is important, the non-error code path is more
>>> important.  Somebody reading a function should be able to easily and
>>> naturally focus on the non-error code.  That works moderately well
>>> today, as the style is "if err != nil { ... }" where the "..." is
>>> indented out of the normal flow.  It's fairly easy for the reader to
>>> skip over the error handling code in order to focus on the non-error
>>> code.  A syntactic construct such as you've written above buries the
>>> lede: what you see first is the error path, but in many cases you
>>> actually want to focus on the non-error path.
>>> 
>>> Ian
>>> 
>>> --
>>> 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/CAOyqgcXHaQk9TfuAz-TUFCsz_-0kDKa_14f3gYER2ufHbhM73Q%40mail.gmail.com.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> 

Re: [go-nuts] Error Handling Question

[Ian Lance Taylor]

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 , out of disk space.  If the code is properly decomposed that function 
> can’t handle it - so it throws - and hopefully a higher level function is 
> able to cope (by handling the specific exception) - maybe asking the user for 
> a different file name or a different destination device.
>
> And the writing function can easily cleanup any temp state due to the stack 
> unwinding and AutoClosable, etc.

I did not mean to imply that that was the only consideration for error handling.

Go style is to avoid exceptions for other reasons
(https://go.dev/doc/faq#exceptions).

Ian


> > On Oct 24, 2022, at 6: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 treated as such, which 
> >> means that the calling function should be able to decide what to do, and 
> >> this should include continuing. Frequently it won't - a lot of error 
> >> handling is just return fmt.Errorf("more context %w", err) - but any 
> >> proposal that assumes that it *always* won't is, IMO, confusing errors 
> >> with panics. This is the question that first started this thread - I 
> >> didn't understand why all the existing error proposals explicitly required 
> >> that a function terminate when it encounters an error, and AFAICT the 
> >> answer is "because people are used to thinking of errors more like panics 
> >> than like return values".
> >
> > For what it's worth, I see this differently.  The existing language is
> > not going to go away, and it's pretty good at handling the cases where
> > an error occurs and the function does not return.  Those cases are by
> > their nature all distinct.  They are not boilerplate.  The way we
> > write them today is fine: easy to read and not too hard to write.
> > When people writing Go complain about error handling, what they are
> > complaining about is the repetitive boilerplate, particularly "if err
> > != nil { return nil, err }".  If we make any substantive changes to
> > the language or standard library for better error handling, that is
> > what we should address.  If we can address other cases, fine, but as
> > they already work OK they should not be the focus of any substantive
> > change.
> >
> >
> >> Is part of the problem that the discussion around the 
> >> try/check/handle/etc. proposals got so involved that nobody wants to even 
> >> consider anything that looks too similar to those? Would it be more 
> >> palatable if I proposed it with names that made it clearer that this is 
> >> about the consolidation of error handling rather than an attempt to 
> >> replace it entirely?
> >>
> >> onErrors {
> >>if must Foo(must Bar(), must Baz()) > 1 {
> >>  ...
> >>   }
> >> } on err {
> >>   ...
> >> }
> >
> > While error handling is important, the non-error code path is more
> > important.  Somebody reading a function should be able to easily and
> > naturally focus on the non-error code.  That works moderately well
> > today, as the style is "if err != nil { ... }" where the "..." is
> > indented out of the normal flow.  It's fairly easy for the reader to
> > skip over the error handling code in order to focus on the non-error
> > code.  A syntactic construct such as you've written above buries the
> > lede: what you see first is the error path, but in many cases you
> > actually want to focus on the non-error path.
> >
> > Ian
> >
> > --
> > 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/CAOyqgcXHaQk9TfuAz-TUFCsz_-0kDKa_14f3gYER2ufHbhM73Q%40mail.gmail.com.

-- 
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/CAOyqgcUBs8UWdHMji-gLK0Z_Lt1mZ59tFaK9YT3UzEQ%2BPYKU8A%40mail.gmail.com.

Re: [go-nuts] Error Handling Question

[Robert Engels]

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 function can’t handle 
it - so it throws - and hopefully a higher level function is able to cope (by 
handling the specific exception) - maybe asking the user for a different file 
name or a different destination device. 

And the writing function can easily cleanup any temp state due to the stack 
unwinding and AutoClosable, etc. 

> On Oct 24, 2022, at 6: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 treated as such, which means 
>> that the calling function should be able to decide what to do, and this 
>> should include continuing. Frequently it won't - a lot of error handling is 
>> just return fmt.Errorf("more context %w", err) - but any proposal that 
>> assumes that it *always* won't is, IMO, confusing errors with panics. This 
>> is the question that first started this thread - I didn't understand why all 
>> the existing error proposals explicitly required that a function terminate 
>> when it encounters an error, and AFAICT the answer is "because people are 
>> used to thinking of errors more like panics than like return values".
> 
> For what it's worth, I see this differently.  The existing language is
> not going to go away, and it's pretty good at handling the cases where
> an error occurs and the function does not return.  Those cases are by
> their nature all distinct.  They are not boilerplate.  The way we
> write them today is fine: easy to read and not too hard to write.
> When people writing Go complain about error handling, what they are
> complaining about is the repetitive boilerplate, particularly "if err
> != nil { return nil, err }".  If we make any substantive changes to
> the language or standard library for better error handling, that is
> what we should address.  If we can address other cases, fine, but as
> they already work OK they should not be the focus of any substantive
> change.
> 
> 
>> Is part of the problem that the discussion around the try/check/handle/etc. 
>> proposals got so involved that nobody wants to even consider anything that 
>> looks too similar to those? Would it be more palatable if I proposed it with 
>> names that made it clearer that this is about the consolidation of error 
>> handling rather than an attempt to replace it entirely?
>> 
>> onErrors {
>>if must Foo(must Bar(), must Baz()) > 1 {
>>  ...
>>   }
>> } on err {
>>   ...
>> }
> 
> While error handling is important, the non-error code path is more
> important.  Somebody reading a function should be able to easily and
> naturally focus on the non-error code.  That works moderately well
> today, as the style is "if err != nil { ... }" where the "..." is
> indented out of the normal flow.  It's fairly easy for the reader to
> skip over the error handling code in order to focus on the non-error
> code.  A syntactic construct such as you've written above buries the
> lede: what you see first is the error path, but in many cases you
> actually want to focus on the non-error path.
> 
> Ian
> 
> -- 
> 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/CAOyqgcXHaQk9TfuAz-TUFCsz_-0kDKa_14f3gYER2ufHbhM73Q%40mail.gmail.com.

-- 
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/19573C66-1957-4F12-A2C4-F6CB9B4A5CD2%40ix.netcom.com.

Re: [go-nuts] Error Handling Question

[Ian Lance Taylor]

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 decide what to do, and this 
> should include continuing. Frequently it won't - a lot of error handling is 
> just return fmt.Errorf("more context %w", err) - but any proposal that 
> assumes that it *always* won't is, IMO, confusing errors with panics. This is 
> the question that first started this thread - I didn't understand why all the 
> existing error proposals explicitly required that a function terminate when 
> it encounters an error, and AFAICT the answer is "because people are used to 
> thinking of errors more like panics than like return values".

For what it's worth, I see this differently.  The existing language is
not going to go away, and it's pretty good at handling the cases where
an error occurs and the function does not return.  Those cases are by
their nature all distinct.  They are not boilerplate.  The way we
write them today is fine: easy to read and not too hard to write.
When people writing Go complain about error handling, what they are
complaining about is the repetitive boilerplate, particularly "if err
!= nil { return nil, err }".  If we make any substantive changes to
the language or standard library for better error handling, that is
what we should address.  If we can address other cases, fine, but as
they already work OK they should not be the focus of any substantive
change.


> Is part of the problem that the discussion around the try/check/handle/etc. 
> proposals got so involved that nobody wants to even consider anything that 
> looks too similar to those? Would it be more palatable if I proposed it with 
> names that made it clearer that this is about the consolidation of error 
> handling rather than an attempt to replace it entirely?
>
> onErrors {
> if must Foo(must Bar(), must Baz()) > 1 {
>   ...
>}
> } on err {
>...
> }

While error handling is important, the non-error code path is more
important.  Somebody reading a function should be able to easily and
naturally focus on the non-error code.  That works moderately well
today, as the style is "if err != nil { ... }" where the "..." is
indented out of the normal flow.  It's fairly easy for the reader to
skip over the error handling code in order to focus on the non-error
code.  A syntactic construct such as you've written above buries the
lede: what you see first is the error path, but in many cases you
actually want to focus on the non-error path.

Ian

-- 
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/CAOyqgcXHaQk9TfuAz-TUFCsz_-0kDKa_14f3gYER2ufHbhM73Q%40mail.gmail.com.

Re: [go-nuts] Error Handling Question

['Axel Wagner' via golang-nuts]

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 in bugs, which are
detected at runtime, which imply that the program is fundamentally
incorrect and can't be relied on.
They are fundamentally different things. Languages with exceptions tend to
use the same (or similar) mechanisms for both, but Go is not one of that.

In Go, the first is an `error`, the second a `panic`. In Java, the first is
an Exception and the second a RuntimeException.

Talking about "checked" vs. "unchecked exception" for the difference
between `return err` and `panic` is IMO misunderstanding the nomenclature.
The difference between those two is "no exception" vs. "exception". The
difference between "checked and unchecked exceptions" is between returning
`error` and returning `*os.PathError`, for example. I would say Go uses
"checked" anything, if the compiler would force a function to declare which
error types it can return and then force the caller to type-switch on those
types.

On Mon, Oct 24, 2022 at 6:31 AM 'Daniel Lepage' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> In practice, though, Go code *does* have a lot of unchecked exception
> usage - every time someone ignores the 'ok' on a type assertion, calls
> panic() or t.Fatal() from a helper function instead of returning an error,
> or writes a MustFoo() version of some function that panics instead of
> returning an error, that's a point where they *could* be using checked
> exceptions (i.e. return values), and have chosen not to because the code is
> easier to write.
>

I am one of the most adamant supporters of gratuitous usage of `panic` I
know of and I almost never do it to make code easier to write. It is always
because 1. I know that a correct program should fulfill some invariant, 2.
the Go type system can't express that, so 3. a panic is the next best thing.
That's even true for the template `Must` functions. In an ideal world, the
compiler would already verify that the template strings are well-formed
(similar to `go vet` does for `Printf`). But it can't, so we have to delay
that type-check to runtime.

Panicing in those situations is the right thing to do, because that code
shouldn't have run in the first place. Pretending that incorrect code can
police itself by returning an error or somesuch is, in my opinion,
delusional. It just leads to an exponentially exploding space of incorrect
states the program could be in and the programmer must consider. And to
*even buggier and less stable* code, because it's impossible to reason
about it.

Writing v.(T) isn't "lazy error handling". It's "I'm restricting the
state-space of the program to those executions in which v has dynamic value
T - I wish the compiler had done it for me".


>
> Regarding your sample code: it's OK but I can think of alternative APIs,
>> depending on how isGreen is intended to be used.
>>
>
> I said earlier that I didn't want to get bogged down on specific examples,
> and this is what I meant - I know that there absolutely are better ways to
> implement the specific example I gave, I was just trying to demonstrate
> that Go not only already allows "expressions that change control flow", but
> in fact has explicit special cases in the language in order to make it
> possible. The "isGreen" example was just to demonstrate this - I know that
> this particular example could be reimplemented to sidestep the problem, but
> I've seen code where this wasn't true (I didn't include any here because
> the examples I can think of are difficult to understand without reading the
> whole of a library first, and I obviously don't expect anyone to do that
> just so that I can make an example).
>
> Reflecting on this more, I think there are several distinct points that
> I'm arguing here. I'll try to make them explicit as I think them through:
>
> *1.* *There are places where streamlining error handling is acceptable
> and encouraged.*
>
> I don't mean that it's *always* good, or even "usually acceptable", just
> that cases do exist where it's desirable.
>
> The evidence for this is strong:
>  * As I mentioned earlier, Go has special case syntax for certain
> operations like type assertions explicitly to streamline error handling. If
> streamlining errors was never a good idea, then Go would require you to
> write f, ok := x.(Foo) even if you know for a fact that x cannot be
> anything but a Foo, the way it currently requires you to write b, err :=
> Bar(x) even if you know for a fact that x is a valid argument for Bar that
> won't cause an error.
>  * In many cases, including in the standard libraries, there are functions
> that return errors and then accompanying functions with names like
> MustFoo() that just call Foo() and panic if there's an error. This is 

Re: [go-nuts] Error Handling Question

['Daniel Lepage' via golang-nuts]

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 exception"; you're panicking,
> which is something different. Go does not encourage this at all.  It would
> be fine to write it that way if calling isGreen on a missing or non-color
> key should never happen - i.e. you know that the programmer seriously
> screwed up if it ever got this far.  But it would almost never be
> appropriate to attempt to recover() from such a situation.
>

When I say "unchecked exception" I mean in the Java sense of "an error
condition that the compiler will not force you to address". The behavior of
an unchecked exception is that it travels up the call stack, aborting each
function until it either reaches the end of the stack and terminates the
program, or reaches a call frame that indicates it will try to recover from
it. This is exactly the behavior of panic - the only difference between
`panic(e)` in Go and `throw e` in Java is that recovery in Java is written
as "catch(Exception)" while in Go it's written as "defer func() { r :=
recover(); ... }()".

Also exactly like in Go, most Java style guides A) discourage you from
throwing unchecked exceptions, and B) agree that it is almost never
appropriate to attempt to catch and recover from one.

The only reason Go doesn't have severe problems with panic/recover being
used everywhere for normal control flow while Java does is because in Java
there's no immediate cost to just declaring your exception type to be a
runtime exception, and it saves you some typing and shuts up some compiler
errors, so people take that shortcut all the time, whereas in Go it's
(correctly, in my opinion) a separate mechanism from checked errors (i.e.
ones where it's a compiler error (usually) to forget to handle them).

In practice, though, Go code *does* have a lot of unchecked exception usage
- every time someone ignores the 'ok' on a type assertion, calls panic() or
t.Fatal() from a helper function instead of returning an error, or writes a
MustFoo() version of some function that panics instead of returning an
error, that's a point where they *could* be using checked exceptions (i.e.
return values), and have chosen not to because the code is easier to write.

Regarding your sample code: it's OK but I can think of alternative APIs,
> depending on how isGreen is intended to be used.
>

I said earlier that I didn't want to get bogged down on specific examples,
and this is what I meant - I know that there absolutely are better ways to
implement the specific example I gave, I was just trying to demonstrate
that Go not only already allows "expressions that change control flow", but
in fact has explicit special cases in the language in order to make it
possible. The "isGreen" example was just to demonstrate this - I know that
this particular example could be reimplemented to sidestep the problem, but
I've seen code where this wasn't true (I didn't include any here because
the examples I can think of are difficult to understand without reading the
whole of a library first, and I obviously don't expect anyone to do that
just so that I can make an example).

Reflecting on this more, I think there are several distinct points that I'm
arguing here. I'll try to make them explicit as I think them through:

*1.* *There are places where streamlining error handling is acceptable and
encouraged.*

I don't mean that it's *always* good, or even "usually acceptable", just
that cases do exist where it's desirable.

The evidence for this is strong:
 * As I mentioned earlier, Go has special case syntax for certain
operations like type assertions explicitly to streamline error handling. If
streamlining errors was never a good idea, then Go would require you to
write f, ok := x.(Foo) even if you know for a fact that x cannot be
anything but a Foo, the way it currently requires you to write b, err :=
Bar(x) even if you know for a fact that x is a valid argument for Bar that
won't cause an error.
 * In many cases, including in the standard libraries, there are functions
that return errors and then accompanying functions with names like
MustFoo() that just call Foo() and panic if there's an error. This is also
error streamlining, and like with type assertions the streamlining comes at
the cost of using panics. Checking sourcegraph.com suggests that hundreds
of Go projects already choose to make this tradeoff:
https://sourcegraph.com/search?q=context:global+lang:go++/func%5Cs%28%5C%28%5B%5E%29%5D%2B%5C%29%5Cs%29%3FMust/=standard
(yes,
some fraction of these are exclusively for module-level initialization, but
at least half of the handful I randomly sampled were being called in other
functions).
* The Ondatra library I linked earlier

Re: [go-nuts] Error Handling Question

[Volker Dobler]

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, updates and changes.

2. The function is easier to _read_ but not necessarily easier
to _understand_ due to more implicite control flow.

I do understand your frustration. I'm annoyed myself at how
much error code I have to write, but honestly: My code is
"better" with all this explicit error handling and in the long
run I'm thankful Go forces me to do it at least halfway right
from the beginning.

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/c594140a-75f6-495b-b0ef-e3d75dc70eb7n%40googlegroups.com.

Re: [go-nuts] Error Handling Question

[Brian Candler]

> 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 does not encourage this at all.  It would 
be fine to write it that way if calling isGreen on a missing or non-color 
key should never happen - i.e. you know that the programmer seriously 
screwed up if it ever got this far.  But it would almost never be 
appropriate to attempt to recover() from such a situation.

panic/recover has two main uses:
1. something very serious went wrong. Either it was a programmer error or 
an internal runtime error; either way, data structures are likely in an 
inconsistent state and it's better to crash than to attempt to carry on.
2. some *very* limited specific use cases which require being able to 
unwind a deep call chain.

Regarding your sample code: it's OK but I can think of alternative APIs, 
depending on how isGreen is intended to be used.

1. The user is allowed to call isGreen on something which may or may not 
exist, or may or may not be a color, and they just want to know if it's a 
green thing or not a green thing.  In that case, return only a bool.

func isGreen(key string) bool {
record := m[key]   // aside: no need for 2-arg form, missing map key 
gives zero value
if record == nil {
return false
}
if !record.IsActive() {
return false
}
cRecord, ok := record.(ColorRecord)
if !ok {
return false
}
return cRecord.Color() == colors.GREEN
}

It's a little verbose, but the intent is absolutely clear, and IMO much 
more obvious that your brief version.  The brief version does raise the 
question "what happens if I call isGreen in situation X, Y or Z"?  The 
answer is "you must never call isGreen in those situations".

2. The user calls isGreen but also wants to know if it was a color thing or 
not.  Then you could return (bool green, bool ok), in the same way to the 
two-argument forms of map lookup and type assertions.

3. The user wants to know exactly *why* it wasn't a color thing.  Then you 
can make it similar to your original code, but return an error which is 
from a set of constants, rather than fmt.Errorf - which is only useful for 
printing and not much more.  That's closest to properly "checked" 
exceptions.

On Saturday, 22 October 2022 at 22:25:16 UTC+2 dple...@google.com wrote:

> I understand what you are saying.  Yes, any function can call panic.
>> Yes, Go also has run-time panics such as division by zero.  Yes, there
>> is code that explicitly uses panic and recover to simplify error
>> handling (you don't have to refer to external packages, there is code
>> like that in the standard library, such as encoding/gob).
>>
>> However, I think my broader point still holds despite those facts.
>>
>
> The part I don't understand is that Go straight-up encourages having a 
> panic instead of handling exceptions in certain specific cases. Suppose I 
> have a map m from string ids to some Record interface, and some of those 
> records satisfy a ColorRecord interface. Then I can write a function that 
> handles exceptions properly like:
>
> func isGreen(key string) (bool, error) {
> record, ok := m[key]
> if !ok || record == nil{
> return false, fmt.Errorf("no record with key %q", key)
> }
> if !record.IsActive() {
> return false, nil
> }
> cRecord, ok := record.(ColorRecord)
> if !ok {
> return false, fmt.Errorf("record with key %q is not a 
> ColorRecord", key)
> }
> return cRecord.Color() == colors.GREEN
> }
>
> Or, I can streamline this considerably by ignoring the second return 
> arguments from type assertions and map lookups, which means if anything 
> goes wrong it'll panic:
>
> func isGreen(key string) bool {
> r := m[key].(ColorRecord)
> return r.IsActive() && r.Color() == colors.GREEN
> }
>
> 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.
>
> The ability to ignore the second return argument is obviously not a 
> standard feature of expressions in go - it's a special case that's 
> hard-coded into the language for a few specific expressions, and as I 
> understand it exists specifically to avoid having to check errors in these 
> expressions. It seems to me that the existence of this language feature 
> proves that there genuinely are cases where most people agree that 
> streamlining exception handling is not just worthwhile, but in fact so 
> useful that we're ok adding special cases to the language itself AND 
> sacrificing compiler-enforced error handling entirely to achieve it.
>
> How does this align with the philosophy that expressions shouldn't ever 
> affect control flow? Or do 

Re: [go-nuts] Error Handling Question

[Ian Lance Taylor]

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 
> > occur in statement context.
>
> This is not true - testing.TB.Fatal, log.Fatal, etc. affect control flow, as 
> do numerous expressions like nil dereferences or zero divisions, and of 
> course any function call that triggers any of those (and in extreme cases 
> like running out of memory practically ANY expression could trigger a control 
> flow change).

I understand what you are saying.  Yes, any function can call panic.
Yes, Go also has run-time panics such as division by zero.  Yes, there
is code that explicitly uses panic and recover to simplify error
handling (you don't have to refer to external packages, there is code
like that in the standard library, such as encoding/gob).

However, I think my broader point still holds despite those facts.


I also want to be clear: I'm happy to talk about these issues.  But
there is basically zero chance that the Go language will add a
try/handle syntactic construct.  It's possible that the language will
make changes regarding error handling, if we ever come to any sort of
consensus as to what can and should be done.  But it's not going to
look like try/handle.

Ian

-- 
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/CAOyqgcUC4Bc17Z-4s10hFHCpKHtHO-KvtCJHgy5u%3DmRHn6xuZQ%40mail.gmail.com.

Re: [go-nuts] Error Handling Question

['Daniel Lepage' via golang-nuts]

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 as a form of "checked"-style error handling. It will
> log what went badly rather and prevents further tests from running. This is
> a reasonable application-level behavior for testing (for non-fatal intent,
> 't.Error' is available).
>

To be clear, I'm not saying that tests shouldn't use `t.Fatal` to stop the
test when a fatal error occurs. I'm just saying that test **helpers* *shouldn't
be using it to get around having to return errors. The fact that existing
projects ARE using it this way suggests not only that tests would benefit
from a more streamlined form of error handling, but also that there are
probably many non-test APIs written in Go that would choose to allow more
concise patterns if Go supported it.

Dan

-- 
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/CAAViQtgyV4sjdjYkYV%2BXJsHiMPT-V%2BbNL_1Z%3D_oywOXSQDvysg%40mail.gmail.com.

Re: [go-nuts] Error Handling Question

['Daniel Lepage' via golang-nuts]

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
error, not panicking.


> 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 particular request triggers
> the bug is low).
>

I don't think handling panics is necessarily indicative of design errors,
but I do agree that it's not something that should be done lightly. A big
part of why Go has largely succeeded in getting people to actually use
checked errors is that recovering from a panic is just complex enough that
you wouldn't attempt it without a really good reason (compared to Java,
where "recovering" from an unchecked exception by ignoring it or tossing in
an empty catch {} block is trivial to write, so people do it all the time,
unfortunately).

But t.Fatal is another panic-like operator, in that it reroutes control
flow without any error handling, and I've seen projects using it as such,
writing `f(t, g(t), h(t))` where each function calls t.Fatal() if anything
goes wrong, instead of having each function return a value and an error.
That's what the Ondatra example I linked was demonstrating - real code in
the wild using t.Fatal as a way to have "unchecked exceptions".

Dan

-- 
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/CAAViQtj%3Dayhoi0XH%2BtDeRJAtgfE6wt81hMszAhG3UiSPLUndJg%40mail.gmail.com.

Re: [go-nuts] Error Handling Question

[Andrew Harris]

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 
went badly rather and prevents further tests from running. This is a 
reasonable application-level behavior for testing (for non-fatal intent, 
't.Error' is available).

On Friday, October 21, 2022 at 2:17:07 PM UTC-7 ren...@ix.netcom.com wrote:

> 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 particular request triggers 
> the bug is low). 
>
> On Oct 21, 2022, at 2:30 PM, 'Daniel Lepage' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> 
>
> > 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 defer() inside a block is just a normal 
> defer, while a handle() inside a block does not apply outside of that block)
> 2. It's confusing to take the previous if err != nil {} blocks that were 
> obviously in response to the preceding line and have the actual handling 
> code be earlier and far away, and
> 3. It would encourage people to just pass errors up without modification, 
> because it's easier to just add a bunch of try's to your code and use the 
> default handler.
>
> My proposal doesn't have these issues - the handler goes with the try 
> block so there's no separate function being deferred and no ambiguity about 
> what code a given handler applies to, the handle block always comes right 
> after the block being try'd, and there is no "default handler" - you can't 
> use check to avoid having any error handling, only to consolidate several 
> error handlers that would be identical.
>
> > 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 occur in statement context.
>
> This is not true - testing.TB.Fatal, log.Fatal, etc. affect control flow, 
> as do numerous expressions like nil dereferences or zero divisions, and of 
> course any function call that triggers any of those (and in extreme cases 
> like running out of memory practically ANY expression could trigger a 
> control flow change).
>
> The link I provided earlier to the Ondatra package demonstrates that 
> real-world Go programmers already ARE using expressions for control flow, 
> by (in this example) calling functions that take a testing.TB and call 
> t.Fatal() if anything goes wrong; the authors clearly decided that this was 
> more readable than using idiomatic error handling.
>
> I see panic/TB.Fatal as being somewhat analogous to Java's unchecked 
> exceptions: they change control flow without warning and you can't be sure 
> what functions trigger them. Errors-as-return-values is analogous to 
> checked exceptions: you explicitly mark things you know could go wrong and 
> the compiler will yell at you if you don't address those possibilities. 
> Java's single biggest mistake (IMO) was making unchecked exceptions easier 
> to use than checked exceptions - as a result many developers just didn't do 
> any error handling at all. Go has mostly avoided this because checking 
> errors is *usually *easier to write and read than using any of 
> the aforementioned unchecked methods, but the t.Fatal examples make it 
> clear that there still are cases where unchecked errors make code easier to 
> read and write. I'm proposing to fix that, not by making unchecked errors 
> harder to use or by turning checked errors into unchecked ones, but rather 
> by streamlining the worst cases in proper error checking, primarily the 
> all-too-common case where "if ComputeSomething(t, FetchThingOne(t), 
> FetchThingTwo(t)) > 1" is so, so much easier to read and write than the 
> equivalent properly checked version (which requires many more lines and 
> several extra variables).
>
> Dan
>
> -- 
> 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/CAAViQtjfE2FdauJ888bu1HC%2BZPPCiff5Bz5_N%3DeM2%3DVtx2fFsg%40mail.gmail.com
>  
> 

Re: [go-nuts] Error Handling Question

[Robert Engels]

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 particular request triggers the bug is 
low). 

> On Oct 21, 2022, at 2:30 PM, 'Daniel Lepage' via golang-nuts 
>  wrote:
> 
> 
> > 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 defer() inside a block is just a normal 
> defer, while a handle() inside a block does not apply outside of that block)
> 2. It's confusing to take the previous if err != nil {} blocks that were 
> obviously in response to the preceding line and have the actual handling code 
> be earlier and far away, and
> 3. It would encourage people to just pass errors up without modification, 
> because it's easier to just add a bunch of try's to your code and use the 
> default handler.
> 
> My proposal doesn't have these issues - the handler goes with the try block 
> so there's no separate function being deferred and no ambiguity about what 
> code a given handler applies to, the handle block always comes right after 
> the block being try'd, and there is no "default handler" - you can't use 
> check to avoid having any error handling, only to consolidate several error 
> handlers that would be identical.
> 
> > 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 
> > occur in statement context.
> 
> This is not true - testing.TB.Fatal, log.Fatal, etc. affect control flow, as 
> do numerous expressions like nil dereferences or zero divisions, and of 
> course any function call that triggers any of those (and in extreme cases 
> like running out of memory practically ANY expression could trigger a control 
> flow change).
> 
> The link I provided earlier to the Ondatra package demonstrates that 
> real-world Go programmers already ARE using expressions for control flow, by 
> (in this example) calling functions that take a testing.TB and call t.Fatal() 
> if anything goes wrong; the authors clearly decided that this was more 
> readable than using idiomatic error handling.
> 
> I see panic/TB.Fatal as being somewhat analogous to Java's unchecked 
> exceptions: they change control flow without warning and you can't be sure 
> what functions trigger them. Errors-as-return-values is analogous to checked 
> exceptions: you explicitly mark things you know could go wrong and the 
> compiler will yell at you if you don't address those possibilities. Java's 
> single biggest mistake (IMO) was making unchecked exceptions easier to use 
> than checked exceptions - as a result many developers just didn't do any 
> error handling at all. Go has mostly avoided this because checking errors is 
> usually easier to write and read than using any of the aforementioned 
> unchecked methods, but the t.Fatal examples make it clear that there still 
> are cases where unchecked errors make code easier to read and write. I'm 
> proposing to fix that, not by making unchecked errors harder to use or by 
> turning checked errors into unchecked ones, but rather by streamlining the 
> worst cases in proper error checking, primarily the all-too-common case where 
> "if ComputeSomething(t, FetchThingOne(t), FetchThingTwo(t)) > 1" is so, so 
> much easier to read and write than the equivalent properly checked version 
> (which requires many more lines and several extra variables).
> 
> Dan
> -- 
> 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/CAAViQtjfE2FdauJ888bu1HC%2BZPPCiff5Bz5_N%3DeM2%3DVtx2fFsg%40mail.gmail.com.

-- 
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/06DD1147-DBE3-4794-85B4-61019BBE1A40%40ix.netcom.com.

Re: [go-nuts] Error Handling Question

['Daniel Lepage' via golang-nuts]

> 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 defer() inside a block is just a normal
defer, while a handle() inside a block does not apply outside of that block)
2. It's confusing to take the previous if err != nil {} blocks that were
obviously in response to the preceding line and have the actual handling
code be earlier and far away, and
3. It would encourage people to just pass errors up without modification,
because it's easier to just add a bunch of try's to your code and use the
default handler.

My proposal doesn't have these issues - the handler goes with the try block
so there's no separate function being deferred and no ambiguity about what
code a given handler applies to, the handle block always comes right after
the block being try'd, and there is no "default handler" - you can't use
check to avoid having any error handling, only to consolidate several error
handlers that would be identical.

> 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
occur in statement context.

This is not true - testing.TB.Fatal, log.Fatal, etc. affect control flow,
as do numerous expressions like nil dereferences or zero divisions, and of
course any function call that triggers any of those (and in extreme cases
like running out of memory practically ANY expression could trigger a
control flow change).

The link I provided earlier to the Ondatra package demonstrates that
real-world Go programmers already ARE using expressions for control flow,
by (in this example) calling functions that take a testing.TB and call
t.Fatal() if anything goes wrong; the authors clearly decided that this was
more readable than using idiomatic error handling.

I see panic/TB.Fatal as being somewhat analogous to Java's unchecked
exceptions: they change control flow without warning and you can't be sure
what functions trigger them. Errors-as-return-values is analogous to
checked exceptions: you explicitly mark things you know could go wrong and
the compiler will yell at you if you don't address those possibilities.
Java's single biggest mistake (IMO) was making unchecked exceptions easier
to use than checked exceptions - as a result many developers just didn't do
any error handling at all. Go has mostly avoided this because checking
errors is *usually *easier to write and read than using any of
the aforementioned unchecked methods, but the t.Fatal examples make it
clear that there still are cases where unchecked errors make code easier to
read and write. I'm proposing to fix that, not by making unchecked errors
harder to use or by turning checked errors into unchecked ones, but rather
by streamlining the worst cases in proper error checking, primarily the
all-too-common case where "if ComputeSomething(t, FetchThingOne(t),
FetchThingTwo(t)) > 1" is so, so much easier to read and write than the
equivalent properly checked version (which requires many more lines and
several extra variables).

Dan

-- 
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/CAAViQtjfE2FdauJ888bu1HC%2BZPPCiff5Bz5_N%3DeM2%3DVtx2fFsg%40mail.gmail.com.

Re: [go-nuts] Error Handling Question

[Ian Lance Taylor]

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 (https://go.dev/issue/32437).  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 occur in
statement context.  After going through the try proposal it's unlikely
that we would adopt that kind of change.

Ian

-- 
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/CAOyqgcWtQ_fEac%3Df0XJaJ_-bHEREqj3ByfirRSdZjQ7Y0Zr_7Q%40mail.gmail.com.

Re: [go-nuts] Error Handling Question

['Daniel Lepage' via golang-nuts]

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 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 already have panic() as a way for a
> function to signal an error it doesn't expect the caller to recover from.
> If a function returns an error instead of panicking, doesn't that mean the
> author of the function believes that it is both possible and reasonable for
> a caller to recover from this error and keep going?
> >
> > I looked through a bunch of different error proposals among the PRs and
> linked from various summary pages, but I can't find if anyone has proposed
> something simple like
> >
> > var x0 float
> > try {
> >x0 = check DoSomeMath(check FetchSomething(), check
> ComputeSomething())
> > } handle err {
> >log.Info("Unable to estimate initial approximation, defaulting to
> 1...")
> >x0 = 1
> > }
> > // code continues and does things with x
> >
> > This makes it easy to see what error handling will happen at any point
> within the function, keeps the control flow linear (so that, unlike
> defer()-based recovery, you don't have to skip ahead in the function to get
> context before the handler makes sense - the context comes first, followed
> by the handling code), and allows code to recover from errors without
> aborting an entire function.
> >
> > As a bonus it'll be easier for new Go programmers to learn because it's
> structured the same way as try/catch or try/except blocks in numerous other
> languages.
> >
> > This seems like an obvious enough suggestion that someone must have made
> it already, but I haven't been able to find that among all the other error
> handling proposals and discussions.
> >
> > Has this in fact been proposed already, and if so where can I find
> discussion on why it was rejected?
>
> I can't recall any error handling proposals that are quite like that,
> though you may want to look at the meta-issue
> https://go.dev/issue/40432.
>
> Most error handling proposals are trying to reduce the boilerplate of
> error checking.  If I rewrite your example with Go as it exists today
> I come up with this:
>
> var x0 float
> x0, err = check DoSomeMath(check FetchSomething(), check
> ComputeSomething())
> if err != nil {
>log.Info("Unable to estimate initial approximation, defaulting to 1...")
>x0 = 1
> }
> // code continues and does things with x
>
> That isn't noticeably longer than what you wrote.  So your suggestion
> doesn't appear to reduce boilerplate much.
>

Sorry, I should have been clearer - what I am proposing is both try/handle
blocks *and* a `check` expression that triggers the handler. The line
`check DoSomeMath(check FetchSomething(), check ComputeSomething())` cannot
(as far as I know) be written in existing Go; in modern Go my example would
have to look something like:

var x0 float
var err error
a, err := FetchSomething()
if err != nil {
   log.Info("Unable to estimate initial approximation, defaulting to 1...")
   x0 = 1
} else {
   b, err := ComputeSomething()
   if err != nil {
  log.Info("Unable to estimate initial approximation, defaulting to
1...")
  x0 = 1
   } else {
  x0, err = DoSomeMath(a, b)
  if err != nil {
 log.Info("Unable to estimate initial approximation, defaulting to
1...")
 x0 = 1
  }
   }
}
// code continues and does things with x

But I also don't want to get bogged down by this specific example - the
above could be somewhat streamlined with an intermediate ComputeX0
function, for example, but that's beside the more general point I'm trying
to make, which is just that there definitely are cases where a function
wants to continue after handling one or more errors, and I am perplexed as
to why every proposal I've seen seems designed to prevent this.


> Specifically, most error handling proposals are focused on reducing
> the boilerplate in
>
> if err != nil {
> return 0, fmt.Errorf("Oh noes: %v", err)
> }
>

TBH I'm less concerned with the boilerplate in general (though I wouldn't
mind reducing it), and more concerned about the specific problem of using
function return values within an expression - I think there are many cases
where it's useful to be able to write code of the form `fn1(fn2())`, but if
fn2 could produce an error then you have to fall back to

tmp, err := fn2()
if err != nil {
return fmt.Errorf(...)
}
fn1(tmp)

which means you're now using temporary variables and obscuring what's
actually happening by sticking a bunch of error handling in between the
various calls.

The premise that being able to chain functions like this is useful is, I
think, validated by the existence of various testing code that passes a
testing.TB 

Re: [go-nuts] Error Handling Question

[Ian Lance Taylor]

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 function continue after detecting an error - this 
> seems weird to me, since we already have panic() as a way for a function to 
> signal an error it doesn't expect the caller to recover from. If a function 
> returns an error instead of panicking, doesn't that mean the author of the 
> function believes that it is both possible and reasonable for a caller to 
> recover from this error and keep going?
>
> I looked through a bunch of different error proposals among the PRs and 
> linked from various summary pages, but I can't find if anyone has proposed 
> something simple like
>
> var x0 float
> try {
>x0 = check DoSomeMath(check FetchSomething(), check ComputeSomething())
> } handle err {
>log.Info("Unable to estimate initial approximation, defaulting to 1...")
>x0 = 1
> }
> // code continues and does things with x
>
> This makes it easy to see what error handling will happen at any point within 
> the function, keeps the control flow linear (so that, unlike defer()-based 
> recovery, you don't have to skip ahead in the function to get context before 
> the handler makes sense - the context comes first, followed by the handling 
> code), and allows code to recover from errors without aborting an entire 
> function.
>
> As a bonus it'll be easier for new Go programmers to learn because it's 
> structured the same way as try/catch or try/except blocks in numerous other 
> languages.
>
> This seems like an obvious enough suggestion that someone must have made it 
> already, but I haven't been able to find that among all the other error 
> handling proposals and discussions.
>
> Has this in fact been proposed already, and if so where can I find discussion 
> on why it was rejected?

I can't recall any error handling proposals that are quite like that,
though you may want to look at the meta-issue
https://go.dev/issue/40432.

Most error handling proposals are trying to reduce the boilerplate of
error checking.  If I rewrite your example with Go as it exists today
I come up with this:

var x0 float
x0, err = check DoSomeMath(check FetchSomething(), check ComputeSomething())
if err != nil {
   log.Info("Unable to estimate initial approximation, defaulting to 1...")
   x0 = 1
}
// code continues and does things with x

That isn't noticeably longer than what you wrote.  So your suggestion
doesn't appear to reduce boilerplate much.

Specifically, most error handling proposals are focused on reducing
the boilerplate in

if err != nil {
return 0, fmt.Errorf("Oh noes: %v", err)
}

That isn't the kind of case that you are describing.  If a function is
going to keep going, then it will almost certainly need some
function-specific code to recover from the error.  That recovery code
is unlikely to be boilerplate.  We could add new syntax to avoid "if
err != nil", but it's not like "if err != nil" is all that long, so
the new syntax seems unlikely to help much.

Ian

-- 
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/CAOyqgcV6TnzfE3dgjBTAGYQBTmfSoRQuOyQcF6LF-Y-a6_AUjg%40mail.gmail.com.

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

[Ian Lance Taylor]

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.  You may want to take a look
at https://golang.org/issue/40432.

Ian

-- 
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/CAOyqgcWpbn0Z8RARap4EDFX1rZwrmxbdFBnCfW1C%3DNUg2jRjow%40mail.gmail.com.

Re: [go-nuts] Error handling

[Michael MacInnis]

>
> 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 originally thought that one of bigger problems with (ab)using panic and 
> recover for control flow and trying to wrap this up in a package would be 
> forgetting to defer the function performing the recover. As mentioned 
> previously I think it's possible to structure things so that it is harder 
> to make this mistake and I think a linter could also be written to catch 
> these cases.
>
> But I think the bigger problem is the function that panics being used 
> after the function with the deferred recover exits or in a different 
> goroutine.
>
> It looks like the Go compiler's escape analysis can be used to detect this 
> though. At least currently. With an inline definition of check and a 
> deferred recover that looks like this:
>
> var check func(error)
> {
> pnc := false
>
> check = func(ce error) { // watch for "func literal escapes to 
> heap"
> if ce != nil {
> err = ce
>
> // Only panic if we haven't previously.
> if !pnc {
> pnc = true
> panic("escaping")
> }
> }
> }
>
> defer func() {
> if pnc {
> _ = recover()
> }
> }()
> }
>
> // Code that uses check.
>
> When compiled with `go build -gcflags -m` if the Go compiler says that the 
> func literal assigned to check escapes to the heap there's a good chance it 
> is being used in a way that won't end well. It even catches uses like this:
>
> c := make(chan struct{})
>
> go func() {
> check(nil)
>
> close(c)
> }()
>
> <-c
>
> where check doesn't out live the function with the deferred recover but it 
> is being used in a different goroutine. So, at least currently, it looks 
> like the compiler can be used to check for unsafe uses of a function like 
> this.
>
> What I'm wondering is are there cases that the compiler won't catch and is 
> this likely to stop working in some future release where, in a block of 
> code like the one above, the compiler will decide that the function doesn't 
> need to escape to the heap?
>
> Michael.
>

-- 
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/d99b705e-d78a-4078-8f8a-ef89a824f58cn%40googlegroups.com.

Re: [go-nuts] Error handling

[robert engels]

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 
wrappers on the common resources so that try-with-resource is as simple as 
possible.

> On Feb 23, 2021, at 1:02 PM, da...@suarezhouse.net  
> wrote:
> 
> 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", you may see 
> "logic" in your exception handler like "if f1 != nil f1.close; if f2 != null 
> f2.close(), etc...".  Having an additional logic point seems "less clean" 
> IMHO than handling it one file at a time as it happens.  If you wanted to add 
> some context around what is special in file 1 - 3 in that example you could 
> also include it in line vs. as a separate logic tree in the exception handler 
> "config file did not load" vs. "data file", etc..  
> 
> I had a different similar problem to the multi-file example where "missing" 
> is normal and while solveable if you change your logic to first check 
> file.exists() not having to add a check for something you already get in the 
> error makes the logic simpler on the page.
> 
> The translation I have become used to is similar to how you started, e.g. 
> Runtime Exception = Panic, Checked Exception = Error.  The one part that I do 
> like in what you mention is the explicit errors in the definition which 
> become part of documentation.  That does force some good habits that need to 
> be done manually today but can potentially be as simple as a vet check on a 
> future comment style if missing and returns an error type.  
> 
> From a value standpoint, the incremental benefit of changes to error seems 
> low compared to the other big changes like generics.
> 
> My .02 if it helps the conversation at all.
> 
> Sincerely,
> David  
> 
> On Tuesday, February 23, 2021 at 7:42:25 AM UTC-6 ren...@ix.netcom.com wrote:
> The complexity there is from generators + exceptions. I am not proposing 
> generators for Go as it doesn’t need it. 
> 
>> On Feb 23, 2021, at 6:03 AM, Nigel Tao > > wrote:
>> 
>> 
> 
>> 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 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/CAOeFMNUEOGf1r-1FpCTFJ0ze9s26ZNqN9vGLGVDoCcaW72%2B9ag%40mail.gmail.com
>>  
>> .
> 
> 
> -- 
> 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/155bf359-2cd3-4d2a-8966-f92d8488426cn%40googlegroups.com
>  
> .

-- 
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/47E656C5-1AD9-4EE5-936D-023C59C9696D%40ix.netcom.com.

Re: [go-nuts] Error handling

[da...@suarezhouse.net]

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", you may see "logic" in your exception handler like "if f1 != nil 
f1.close; if f2 != null f2.close(), etc...".  Having an additional logic 
point seems "less clean" IMHO than handling it one file at a time as it 
happens.  If you wanted to add some context around what is special in file 
1 - 3 in that example you could also include it in line vs. as a separate 
logic tree in the exception handler "config file did not load" vs. "data 
file", etc..  

I had a different similar problem to the multi-file example where "missing" 
is normal and while solveable if you change your logic to first check 
file.exists() not having to add a check for something you already get in 
the error makes the logic simpler on the page.

The translation I have become used to is similar to how you started, e.g. 
Runtime Exception = Panic, Checked Exception = Error.  The one part that I 
do like in what you mention is the explicit errors in the definition which 
become part of documentation.  That does force some good habits that need 
to be done manually today but can potentially be as simple as a vet check 
on a future comment style if missing and returns an error type.  

>From a value standpoint, the incremental benefit of changes to error seems 
low compared to the other big changes like generics.

My .02 if it helps the conversation at all.

Sincerely,
David  

On Tuesday, February 23, 2021 at 7:42:25 AM UTC-6 ren...@ix.netcom.com 
wrote:

> The complexity there is from generators + exceptions. I am not proposing 
> generators for Go as it doesn’t need it. 
>
> On Feb 23, 2021, at 6:03 AM, Nigel Tao  wrote:
>
> 
>
> 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 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/CAOeFMNUEOGf1r-1FpCTFJ0ze9s26ZNqN9vGLGVDoCcaW72%2B9ag%40mail.gmail.com
>  
> 
> .
>
>

-- 
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/155bf359-2cd3-4d2a-8966-f92d8488426cn%40googlegroups.com.

Re: [go-nuts] Error handling

[Nigel Tao]

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 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/CAOeFMNUEOGf1r-1FpCTFJ0ze9s26ZNqN9vGLGVDoCcaW72%2B9ag%40mail.gmail.com.

Re: [go-nuts] Error handling

[robert engels]

> 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 because there is none, or it is difficult 
>> to communicate.
>> 
> 
> I think since this is a Go list, the onus is on advocates of exceptions to 
> demonstrate the benefit of checked exceptions over error return values.
> 
> Here are a couple of scenarios that I encountered recently that had logical 
> linear flow with error returns. I'm curious how they would be improved with 
> checked exceptions:
> 
> 1) open three files for writing, closing the earlier ones if a subsequent one 
> fails to open
> 
The requests are a little basic and lead to trivial solutions, like this:

public static void writeFiles()  throws IOException {

try(FileOutputStream f1 = new FileOutputStream("file1");
FileOutputStream f2 = new FileOutputStream("file2");
FileOutputStream f3 = new FileOutputStream("file3")
) {
// at this point all files are open for writing and ready to be 
processed
// if any open failed, the other files are closed
}
}

> 2) open a file for append, falling back to creating a new writeable file if 
> the original is read-only or doesn't exist. The new file creation may also 
> fail due to disk errors or permissions.
> 

Technically, this is just as trivial because of the way the stdlib implements 
this:

public static void openFile() throws IOException {

try(FileOutputStream f1 = new FileOutputStream("somefile",true);
) {
// at this the file is open for writing and will be closed when the 
block/method exits
}
}

But lets assume that method failed if 'open for append' failed if the file 
didn’t exist:

class Test {
private static FileOutputStream openAppendOrCreate(String name) throws 
FileNotFoundException {
try {
return new FileOutputStream(name,true);
} catch(FileNotFoundException e){
return new FileOutputStream(name);
}
}

public static void openFile()  throws IOException {

try(FileOutputStream f1 = openAppendOrCreate("somefile");
) {
// at this the file is open for writing and will be closed when the 
block exits
}
}
}
Still, in a significant system and this being a core operation I wouldn’t rely 
on so much stdlib convenience/behavior and would instead use more low-level 
methods that take a File, checking for existence and writability, etc. but the 
basic pattern of wrapping ‘resource creation’ into a method to improve 
readability and keep the try-with-resource blocks simple.

If you need to delete a file in addition to closing when the block exits you 
are better off using a ‘resource creation’ method that creates a wrapper stream 
that deletes on close. Or you could use the various ‘create temp’ file methods 
and ‘delete on exit’ and let the platform handle the clean-up.

> I can envisage how to write them with exceptions but I'm struggling to see 
> where it would be more succinct or easier to read.
> 
> 
> -- 
> 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/9f3cf023-5bb4-49da-a842-0be97904d21a%40www.fastmail.com.

-- 
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/41BAFD5D-F6A9-4069-8B36-7BD2C85D9D3B%40ix.netcom.com.

Re: [go-nuts] Error handling

[robert engels]

> 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 ‘return 
> error value’?
> 
> I stated and restated benefits of 'Go-way' earlier in this thread twice. I 
> can only add what IMO is wrong with java exceptions:
> 
> - failure context in scope is lost. Welcome back to the early C times and 
> declare everything you might need before you open the try block.

Much of this was alleviated with try-with-resource. Even Go’s defer is not 
perfect here, since the parameters are captured early - which leaves no choice 
but to use the same pattern in Go/Java.

> 
> - you have to handle failures at distance. (Or sprinkle your code with 
> 'try-catch-es in density similar to Go's if-err-not-nil-es.)
> 
> - you need to be aware of exceptional flows within flow of exceptions - 
> accounting for niceties that may vary from implementation to implementation 
> of prosthetic added to alleviate practical shortcomings of the whole 
> exceptions concept:
> 
 If an exception is thrown from the try block and one or more exceptions are
 thrown from the try-with-resources statement, then those exceptions thrown
 from the try-with-resources statement are suppressed, and the exception 
 thrown
 by the block is the one that is thrown by the writeToFileZipFileContents 
 method.
 You can retrieve these suppressed exceptions by calling the 
 Throwable.getSuppressed
 method from the exception thrown by the try block.
> 
> Exceptions in all their glory as seen in the wild (in Oracle Java docs).

This is exactly the Scan() / ErrWriter pattern as expressed in the blog post - 
but superior as you have a top-level exception generated - no such capability 
in the Go model.

> 
> 

I am not sure what you would expect to happen here. If the primary failure was 
due to a disk controller failure, and yet you try to close the file in the 
exception handler, you are going to get another exception. In either case, this 
should propagated as a ‘unable to write file’ (not an unable to close file). 
Now, your handler could attempt to write the file elsewhere, and again would 
ignore any exception (or log) any exception on the original write or close. It 
all depends on the semantics of the method and what it is expected to achieve.


>> The ‘handle where they occur claim’ is weak, as you can handle exceptions at 
>> the call site with similar LOC and constructs - but why
>> when in most cases (of non-trivial software) the error value is just 
>> returned up.
> 
> IMO "when in most cases…is just returned/thrown up" is an accessory damage 
> done to the generation exposed to exceptionally toxic fumes of convoluted 
> exception flows ;). No offense to Robert.

See the Scan() and ErrWriter in the blog post - this is essentially what is 
done. If you have no possibly way of knowing the intermediary errors all you 
can do is throw up your hands because you can’t possibly know the state of the 
system. When this pattern is mixed with other code look out below.

> 
>> No offense to Wojciech - the rpc transport layer doesn’t do the retires, it 
>> passes up an error, and a higher level performs retry logic, if all retries 
>> fail, it will pass up another error that the rpc failed, etc. This pattern 
>> is used throughout well designed software. 
> 
>> If you hard using this pattern you are creating very hard to maintain 
>> software.
> 
> I hardly use other working with std libraries. But where I can I keep the 
> unit sealed, testable as a black-box and replaceable. Go helps with that.
> 
>> Checked exceptions are ‘error values’ with more information (e.g stack 
>> traces, causes, etc.)
> 
> This (more information everywhere) is also a fallacy stem mostly from the 
> exceptions philosophy. I need not to build objects and move piles of data my 
> code can not deal with. In Go I log this at the place of occurrence (for the 
> human consumption at debug/forensics time). All what code up needs to know is 
> whether this was a recoverable failure or an error. Try to recover if former, 
> give up and tell supervisor if later.

Ah, but then you have brittle software, or at least limited re-use. Every time 
you make the decision to I’ll just log here and ignore because I know best, 
limits the ability of some other system using the code. You can argue that code 
re-use is a falicy - I would not.
> 
>> Can be enforced by the compiler (declared) and inspected by modern IDE’s for 
>> code complete.
> 
> Um... What compiler can enforce inside an 'foff/todo' (empty) catch block? 
> Note that this empty catch can be silently placed way out of sight to not 
> bother us in our happy flow reading experience. In Go this attitude, while it 
> takes just two strokes, is visible in-place as a glaring 

Re: [go-nuts] Error handling

[Wojciech S. Czarnecki]

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 this thread twice. I can 
only add what IMO is wrong with java exceptions:

- failure context in scope is lost. Welcome back to the early C times and 
declare everything you might need before you open the try block.

- you have to handle failures at distance. (Or sprinkle your code with 
'try-catch-es in density similar to Go's if-err-not-nil-es.)

- you need to be aware of exceptional flows within flow of exceptions - 
accounting for niceties that may vary from implementation to implementation of 
prosthetic added to alleviate practical shortcomings of the whole exceptions 
concept:

>>> If an exception is thrown from the try block and one or more exceptions are
>>> thrown from the try-with-resources statement, then those exceptions thrown
>>> from the try-with-resources statement are suppressed, and the exception 
>>> thrown
>>> by the block is the one that is thrown by the writeToFileZipFileContents 
>>> method.
>>> You can retrieve these suppressed exceptions by calling the 
>>> Throwable.getSuppressed
>>> method from the exception thrown by the try block.

Exceptions in all their glory as seen in the wild (in Oracle Java docs).


> The ‘handle where they occur claim’ is weak, as you can handle exceptions at 
> the call site with similar LOC and constructs - but why
> when in most cases (of non-trivial software) the error value is just returned 
> up.

IMO "when in most cases…is just returned/thrown up" is an accessory damage done 
to the generation exposed to exceptionally toxic fumes of convoluted exception 
flows ;). No offense to Robert.

>  No offense to Wojciech - the rpc transport layer doesn’t do the retires, it 
> passes up an error, and a higher level performs retry logic, if all retries 
> fail, it will pass up another error that the rpc failed, etc. This pattern is 
> used throughout well designed software. 

> If you hard using this pattern you are creating very hard to maintain 
> software.

I hardly use other working with std libraries. But where I can I keep the unit 
sealed, testable as a black-box and replaceable. Go helps with that.

> Checked exceptions are ‘error values’ with more information (e.g stack 
> traces, causes, etc.)

This (more information everywhere) is also a fallacy stem mostly from the 
exceptions philosophy. I need not to build objects and move piles of data my 
code can not deal with. In Go I log this at the place of occurrence (for the 
human consumption at debug/forensics time). All what code up needs to know is 
whether this was a recoverable failure or an error. Try to recover if former, 
give up and tell supervisor if later.

> Can be enforced by the compiler (declared) and inspected by modern IDE’s for 
> code complete.

Um... What compiler can enforce inside an 'foff/todo' (empty) catch block? Note 
that this empty catch can be silently placed way out of sight to not bother us 
in our happy flow reading experience. In Go this attitude, while it takes just 
two strokes, is visible in-place as a glaring lhs underscore.

> BUT you should not be using exceptions - or error values - for flow control.
  WUT? 

Every Java book 'exceptions' chapter starts along the 'use checked exceptions 
for the flow control' lines:

>>> [Joshua Bloch, Effective java] Item 40: Use checked exceptions for 
>>> recoverable conditions and runtime exceptions for programming errors. E.g. 
>>> host is down, throw checked exception so the caller can either pass in a 
>>> different host address or move on to something else.
>>> Item 41: Avoid unnecessary use of checked exceptions.


> This is the fundamental problem to me with Go’s error handling - 
> the flow control and errors are mixed

Whether you want it or not, you must choose the path if a failure or an error 
happens.

> leading to very difficult code to read

(In Go) leading to code that does what it says. And a code that says explicit 
what it is about to do if just called piece of code did not know what to do. 
All in sight. The happy path can be exposed in an IDE with a fold switch [see 
PS].

>code difficult to validate that all potential paths are handled now and in the 
>future.

Java compiler can validate only sad paths that it has been explicitly told of 
using 'throws' clause. Hardly 'all potential…and in the future'.

All in all: both java and Go ways are already established and used. Both are 
slowly evolving. Arguing them here over and over will not change Go usage 
patterns with even an iota for the simple fact Go does not support exceptions.

P.S. You, Robert, could make a gift for others who'd like to have "lucid happy 
path view" by amending mainstream IDEs folding code with "fold to finger" 
functionality. I mean, let the 

Re: [go-nuts] Error handling

[Robert Engels]

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, 2021, at 8:52 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 because there is none, or it is difficult 
>> to communicate.
>> 
> 
> I think since this is a Go list, the onus is on advocates of exceptions to 
> demonstrate the benefit of checked exceptions over error return values.
> 
> Here are a couple of scenarios that I encountered recently that had logical 
> linear flow with error returns. I'm curious how they would be improved with 
> checked exceptions:
> 
> 1) open three files for writing, closing the earlier ones if a subsequent one 
> fails to open
> 
> 2) open a file for append, falling back to creating a new writeable file if 
> the original is read-only or doesn't exist. The new file creation may also 
> fail due to disk errors or permissions.
> 
> I can envisage how to write them with exceptions but I'm struggling to see 
> where it would be more succinct or easier to read.
> 
> 
> -- 
> 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/9f3cf023-5bb4-49da-a842-0be97904d21a%40www.fastmail.com.

-- 
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/D4D23F5D-E685-4873-BEA1-6F0179F0347D%40ix.netcom.com.

Re: [go-nuts] Error handling

[Ian Davis]

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

I think since this is a Go list, the onus is on advocates of exceptions to 
demonstrate the benefit of checked exceptions over error return values.

Here are a couple of scenarios that I encountered recently that had logical 
linear flow with error returns. I'm curious how they would be improved with 
checked exceptions:

1) open three files for writing, closing the earlier ones if a subsequent one 
fails to open

2) open a file for append, falling back to creating a new writeable file if the 
original is read-only or doesn't exist. The new file creation may also fail due 
to disk errors or permissions.

I can envisage how to write them with exceptions but I'm struggling to see 
where it would be more succinct or easier to read.


-- 
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/9f3cf023-5bb4-49da-a842-0be97904d21a%40www.fastmail.com.

Re: [go-nuts] Error handling

[Ian Lance Taylor]

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 a few times and it goes to crickets - 
> >> I have to believe that is because there is none, or it is difficult to 
> >> communicate.
> >
> > As I wrote earlier, I believe that experience shows that it is
> > extremely difficult to write a large scale program with multiple
> > maintainers that uses checked exceptions.  In practice, programs
> > always fall back to unchecked exceptions.  So I would say that one
> > benefit of error return over checked exceptions is simply that error
> > returns scale to large programs and many maintainers.
> >
> I don’t think answering, “people fall back to unchecked exceptions” is an 
> answer to “how do error returns and checked exceptions differ”.

But that isn't the question you asked.  I was trying to answer the
question quoted above: "Can someone please explain the benefit of
‘error return’ over ‘checked exceptions’ ?"

My answer to this new question "how do error returns and checked
exceptions differ” would be one about visible control flow.


> I can provide examples for each case in the blog as to why it seems more 
> 'defensive justification’ rather than evidence of being better.

We disagree.


> Exceptions as advanced error values as more benefits:
>
>1. the developer needs to declare what exceptions the method throws if any
>- this is unbelievably valuable for efficient development and 
> maintenance - rather than trying to read through documentation (hopefully up 
> to date) or code to try and figure out all of the possible errors a method 
> will return and what they mean

As I've said a couple of times, I don't think this works in actual
practice for large programs with multiple authors.  Those programs
wind up falling back to unchecked exceptions, and this advantage is
lost.  I don't consider this to be a controversial opinion; a number
of people have pointed this out.

>2. the ‘value’ of an exception contains a lot more information by default
> - often no need to wrap, as the stack trace provides sufficient 
> information, and a ‘developer label’ can easily become out of date

Sure, that is both an advantage and a disadvantage (a disadvantage
because it means that you pay a cost for every error, and that cost
may not be appropriate in all cases).

Ian

-- 
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/CAOyqgcURf_mBRO0isfh-i-x0ch24eBG7Q-nMGMtk32%3DgkOsqEA%40mail.gmail.com.

Re: [go-nuts] Error handling

[robert engels]

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 believe that is because there is none, or it is difficult to 
>> communicate.
> 
> As I wrote earlier, I believe that experience shows that it is
> extremely difficult to write a large scale program with multiple
> maintainers that uses checked exceptions.  In practice, programs
> always fall back to unchecked exceptions.  So I would say that one
> benefit of error return over checked exceptions is simply that error
> returns scale to large programs and many maintainers.
> 
I don’t think answering, “people fall back to unchecked exceptions” is an 
answer to “how do error returns and checked exceptions differ”.

> Another benefit is described by Rob's blog post, which I'm sure you've
> seen: Errors are values (https://blog.golang.org/errors-are-values).
> 
> More generally, errors are not exceptional conditions.  They are part
> and parcel of how programs work.  They are part of the normal program
> flow, and they should be part of that flow.  They shouldn't be
> regarded as exceptional and unusual flow.
> 
Yes, with all due respect to Rob, we'll probably disagree on that blog post. 
Take the Scan() example. This is a justification of how to write code that 
isn’t painful when you don't have exceptions - instead it puts the burden on 
the writer of Scan() to set a boolean internally to ‘don’t do anything’, write 
an additional method Err(), check the boolean on all other methods, etc., then 
the caller needs to remember to call Err() after all processing - and the code 
might loop through a billion elements doing nothing - potentially creating huge 
inefficiencies. Lastly, a reader of the code where the developer had failed to 
call Err() would not know unless they were intimately aware of the particular 
API - this is not good for long term maintenance. 

I can provide examples for each case in the blog as to why it seems more 
'defensive justification’ rather than evidence of being better.

> I'm not going to claim that any of these benefits are slam dunks.  If
> there were obvious solutions to how to handle errors, nobody would
> still be discussing different approaches.  But I am claiming that Go's
> approach to error handling has real benefits.
> 
> 
>> The ‘handle where they occur claim’ is weak, as you can handle exceptions at 
>> the call site with similar LOC and constructs - but why when in most cases 
>> (of non-trivial software) the error value is just returned up. No offense to 
>> Wojciech - the rpc transport layer doesn’t do the retires, it passes up an 
>> error, and a higher level performs retry logic, if all retries fail, it will 
>> pass up another error that the rpc failed, etc. This pattern is used 
>> throughout well designed software. If you hard using this pattern you are 
>> creating very hard to maintain software.
> 
> I can't agree that in most cases the error is just returned up.  I
> would agree that within a single package an error is often (but not
> always) returned up without change.  But in large Go programs that
> I've seen, when error values cross package boundaries, they are almost
> always annotated with additional information.
> 
> 

There is no difference between

if err != nil {
return someWrappingMethod(err)
}

and

catch (SomeException e) {
throw SomeOtherException(e);
}

but, if you don’t want or can’t provide additional information you don’t need 
to do anything, BUT you still have to declare that your method throws the 
exception - this is an important benefit.

and if you have several methods or loops that throw the exception you can move 
the handler to outside - in Go this is plain tiresome and ugly - the blog post 
tries to handle this with the Scan() and ErrWriter() - again - not handling the 
errors as they occur (so no, Go code doesn’t ‘read’ linearly - many of the LOC 
may become noops interspersed with other non-noop code which is a nightmare).

Exceptions as advanced error values as more benefits:

   1. the developer needs to declare what exceptions the method throws if any
   - this is unbelievably valuable for efficient development and 
maintenance - rather than trying to read through documentation (hopefully up to 
date) or code to try and figure out all of the possible errors a method will 
return and what they mean
   2. the ‘value’ of an exception contains a lot more information by default
- often no need to wrap, as the stack trace provides sufficient 
information, and a ‘developer label’ can easily become out of date


>> Checked exceptions are ‘error values’ with more information (e.g stack 
>> traces, causes, etc.), and can be enforced by the compiler (declared) and 
>> inspected by modern IDE’s for code complete. 

Re: [go-nuts] Error handling

[Ian Lance Taylor]

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.

As I wrote earlier, I believe that experience shows that it is
extremely difficult to write a large scale program with multiple
maintainers that uses checked exceptions.  In practice, programs
always fall back to unchecked exceptions.  So I would say that one
benefit of error return over checked exceptions is simply that error
returns scale to large programs and many maintainers.

Another benefit is described by Rob's blog post, which I'm sure you've
seen: Errors are values (https://blog.golang.org/errors-are-values).

More generally, errors are not exceptional conditions.  They are part
and parcel of how programs work.  They are part of the normal program
flow, and they should be part of that flow.  They shouldn't be
regarded as exceptional and unusual flow.

I'm not going to claim that any of these benefits are slam dunks.  If
there were obvious solutions to how to handle errors, nobody would
still be discussing different approaches.  But I am claiming that Go's
approach to error handling has real benefits.


> The ‘handle where they occur claim’ is weak, as you can handle exceptions at 
> the call site with similar LOC and constructs - but why when in most cases 
> (of non-trivial software) the error value is just returned up. No offense to 
> Wojciech - the rpc transport layer doesn’t do the retires, it passes up an 
> error, and a higher level performs retry logic, if all retries fail, it will 
> pass up another error that the rpc failed, etc. This pattern is used 
> throughout well designed software. If you hard using this pattern you are 
> creating very hard to maintain software.

I can't agree that in most cases the error is just returned up.  I
would agree that within a single package an error is often (but not
always) returned up without change.  But in large Go programs that
I've seen, when error values cross package boundaries, they are almost
always annotated with additional information.


> Checked exceptions are ‘error values’ with more information (e.g stack 
> traces, causes, etc.), and can be enforced by the compiler (declared) and 
> inspected by modern IDE’s for code complete. ‘error returns’ have none of 
> these features. The only valid claim is that they are more expensive than 
> error values, BUT you should not be using exceptions - or error values - for 
> flow control. This is the fundamental problem to me with Go’s error handling 
> - the flow control and errors are mixed leading to very difficult code to 
> read & validate that all potential paths are handled now and in the future.

My opinion, which contradicts yours, is that when the flow control is
written down on the page, as it is in Go, the flow is easy to read,
and it is much easier to check that all potential paths are handled.
With exceptions the control flow is not written down, so it is easier
to miss cases where an exception can arise.  With exceptions the
normal control flow is easier to see, but the error control flow is
harder.  And since the error control flow happens less frequently,
it's more important to make it clearly visible to the original
programmer and, more importantly, to the future maintainer.

Again, no slam dunks here.  Reasonable people can disagree.  But I
think the Go position is entirely defensible for large scale programs
with many programmers.

Ian

-- 
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/CAOyqgcW2uhrVv%2Br9Z1AdQdzGZN9JnRBWsZ6CoAQ0dg46RZGpCA%40mail.gmail.com.

Re: [go-nuts] Error handling

[robert engels]

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 exceptions at 
the call site with similar LOC and constructs - but why when in most cases (of 
non-trivial software) the error value is just returned up. No offense to 
Wojciech - the rpc transport layer doesn’t do the retires, it passes up an 
error, and a higher level performs retry logic, if all retries fail, it will 
pass up another error that the rpc failed, etc. This pattern is used throughout 
well designed software. If you hard using this pattern you are creating very 
hard to maintain software.

Checked exceptions are ‘error values’ with more information (e.g stack traces, 
causes, etc.), and can be enforced by the compiler (declared) and inspected by 
modern IDE’s for code complete. ‘error returns’ have none of these features. 
The only valid claim is that they are more expensive than error values, BUT you 
should not be using exceptions - or error values - for flow control. This is 
the fundamental problem to me with Go’s error handling - the flow control and 
errors are mixed leading to very difficult code to read & validate that all 
potential paths are handled now and in the future.



> On Feb 21, 2021, at 10:10 AM, Wojciech S. Czarnecki  wrote:
> 
> 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 production code, mine's.
> 
>> I'd like to know if, for functions like the 
>> ones just mentioned, a pattern exists for "eliminating 
> 
>> much of the boilerplate that arises if every error is checked with a rote if
> 
> I said twice that for me it is not "boilerplate" but much appreciated feature
> of the language whose creators knew and acknowledged that every piece of
> code is written once by one developer but is then being read over and over
> by way more people than one.
> 
> And I have had not less emphatically told that where there is a function
> that just returns with err, even in "many places", the bytewise cost of return
> is some 30 bytes usually placed by the IDE with three strokes of mine.
> 
> For these three strokes where I just return (now):
> 
> As a reader I gained clear information that here something was checked then
> function just spilled error up *but* I have the surrounding context at sight.
> 
> As an author I gained - now or later:
> - A ready space to comment on and/or decorate the error value.
> - If I am decorating or creating error value, I am right in scope.
> - If this is recoverable failure, I can try to recover it now.
> 
>> And further if that pattern can be implemented as a library/package
>> with acceptable trade offs.
> 
> In this thread it was proven that this antipattern can be implemented
> as a library/package - using import, then setup, then a call to obscure
> function - all to replace a 26 or 30 bytes long idiom - by Michael Ellis.
> 
>> I'd like to know if, for functions like the 
>> If … a pattern exists for "eliminating [ these "ifs" ]
> 
> Yes it does exist. I once upon a time did a "fail" package and accompanying
> generator to implement such "if-less" pattern to use in a cases where cost
> of acquiring a resource is high and a bunch (say 8-10) of such resources is
> needed to complete the task. It was a waste of time, as new people need to
> be taught to read and understand it anyway. So it was abandoned due to
> onboarding issues. It really was not worth the time.
> 
> ``` go
> for fail.With(err) { // bind an error type variable,
>s, abort := fail.Simple() // set up a single pass loop
>abort.Where(err != nil, !ok, z < 0) // set common "failure" condition(s)
> 
>  z := z  // test z < 0 (a "checked assignment")
>  r, ok := <-ch   // test !ok
>  x, y, z, err := f(z, r) // test err != nil, then test z < 0
>  abort.If(x > y) // test x > y (a "plain test")
>  x, y, err = m(x, y) // test err != nil
>  return x, y, z, nil // can be prepended by an optional 'pass:'
> 
> abort:
>  fmt.Printf("‖ %s: \t( %s )\n", err.Error(), s.Trig)
>  return 0, 0, 0, err
> }
> // output:
> ‖ failed Test: ( x > y )   // for x > y
> ‖ failed Assignment: ( !ok )  // for closed ch
> ‖ failed Assignment: ( z < 0 )   // for z < 0
> ‖ Whatever err said: ( err != nil )  // for failed f(z, r) and m(x, y)
> ```
> 
> Early iteration (live example) to be seen here: 
> https://play.golang.org/p/W35BVsZnZ-q
> 
> Hope this helps,
> 
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
> 
> -- 
> You received this message because you are subscribed to the Google 

Re: [go-nuts] Error handling

[Wojciech S. Czarnecki]

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 production code, mine's.

> I'd like to know if, for functions like the 
> ones just mentioned, a pattern exists for "eliminating 

> much of the boilerplate that arises if every error is checked with a rote if

I said twice that for me it is not "boilerplate" but much appreciated feature
of the language whose creators knew and acknowledged that every piece of
code is written once by one developer but is then being read over and over
by way more people than one.

And I have had not less emphatically told that where there is a function
that just returns with err, even in "many places", the bytewise cost of return
is some 30 bytes usually placed by the IDE with three strokes of mine.

For these three strokes where I just return (now):

As a reader I gained clear information that here something was checked then
function just spilled error up *but* I have the surrounding context at sight.

As an author I gained - now or later:
- A ready space to comment on and/or decorate the error value.
- If I am decorating or creating error value, I am right in scope.
- If this is recoverable failure, I can try to recover it now.

> And further if that pattern can be implemented as a library/package
> with acceptable trade offs.

In this thread it was proven that this antipattern can be implemented
as a library/package - using import, then setup, then a call to obscure
function - all to replace a 26 or 30 bytes long idiom - by Michael Ellis.

> I'd like to know if, for functions like the 
> If … a pattern exists for "eliminating [ these "ifs" ]

Yes it does exist. I once upon a time did a "fail" package and accompanying
generator to implement such "if-less" pattern to use in a cases where cost
of acquiring a resource is high and a bunch (say 8-10) of such resources is
needed to complete the task. It was a waste of time, as new people need to
be taught to read and understand it anyway. So it was abandoned due to
onboarding issues. It really was not worth the time.

``` go
for fail.With(err) { // bind an error type variable,
s, abort := fail.Simple() // set up a single pass loop
abort.Where(err != nil, !ok, z < 0) // set common "failure" condition(s)

  z := z  // test z < 0 (a "checked assignment")
  r, ok := <-ch   // test !ok
  x, y, z, err := f(z, r) // test err != nil, then test z < 0
  abort.If(x > y) // test x > y (a "plain test")
  x, y, err = m(x, y) // test err != nil
  return x, y, z, nil // can be prepended by an optional 'pass:'

abort:
  fmt.Printf("‖ %s: \t( %s )\n", err.Error(), s.Trig)
  return 0, 0, 0, err
}
// output:
‖ failed Test: ( x > y )   // for x > y
‖ failed Assignment: ( !ok )  // for closed ch
‖ failed Assignment: ( z < 0 )   // for z < 0
‖ Whatever err said: ( err != nil )  // for failed f(z, r) and m(x, y)
```

Early iteration (live example) to be seen here: 
https://play.golang.org/p/W35BVsZnZ-q

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20210221171014.2c247c6d%40xmint.

Re: [go-nuts] Error handling

[Michael MacInnis]

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:

https://blog.golang.org/errors-are-values

Another example is the CopyFile function from "Error Handling - Problem 
Overview":

https://github.com/golang/proposal/blob/master/design/go2draft-error-handling-overview.md

In these cases the caller may be better equipped to know what to do next 
when there is an error.

The "Errors are Values" post gives some examples of using the language to 
simplify error handling. The check/handle and try proposals do the same 
thing but by proposing language changes. I don't believe any of them are 
proposing not checking and/or not handling errors.

I can tell you most emphatically that I am not proposing not checking 
and/or not handling errors. I'd like to know if, for functions like the 
ones just mentioned, a pattern exists for "eliminating much of the 
boilerplate that arises if every error is checked with a rote if 
statement." And further if that pattern can be implemented as a 
library/package with acceptable trade offs.

Michael.

On Saturday, February 20, 2021 at 6:54:39 PM UTC-5 ohir wrote:

> 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 consists of two small functions, 
> > ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows:
>
> > in the common case where a function simply wants to return an error to 
> its caller.
>
> There is no trade off here for me (an likely many others). It is idiomatic 
> versus weird:
>
> 1. hit !er move on coding (in fact MY shortcut puts panic instead 
> of return).
>
> 2. USE: import (write) a module, setup defer stack, confuse first-time 
> reader, write a call, move on.
>
> Note that both versions on my vim take just one line off the screen 
> estate. This is true for any IDE able to fold. OK - idiomatic would take 
> two lines more if code is viewed in pager or using MS Word.
>
> > in the common case where a function simply wants to return an error to 
> its caller.
>
> It is NOT a "common" case.
>
> In the "boring" production code we are expected that any service exposed 
> to the end-user will never refuse to work, our code must try really hard to 
> complete, retrying at other server here, then at other city's or continent 
> server room until its real task can be successfully done. Resources (eg. 
> network services) needs to be acquired, then vetted, then operated on, then 
> finally released in a consistent state. 
>
> So we don't throw "something went wrong" (ie. unhandled exception) up. Nor 
> we do "Return if any error". We do check errors, then
> retry in loops. Go explicit, IN PLACE handling helps with that alot.
>
> TC,
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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/c54ded01-20af-4a92-b10c-f85438ed136bn%40googlegroups.com.

Re: [go-nuts] Error handling

[Wojciech S. Czarnecki]

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 consists of two small functions, 
> ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows:

> in the common case where a function simply wants to return an error to its 
> caller.

There is no trade off here for me (an likely many others). It is idiomatic 
versus weird:

1. hit !er move on coding (in fact MY shortcut puts panic instead of 
return).

2. USE: import (write) a module, setup defer stack, confuse first-time reader, 
write a call, move on.

Note that both versions on my vim take just one line off the screen estate. 
This is true for any IDE able to fold. OK - idiomatic would take two lines more 
if code is viewed in pager or using MS Word.

> in the common case where a function simply wants to return an error to its 
> caller.

It is NOT a "common" case.

In the "boring" production code we are expected that any service exposed to the 
end-user will never refuse to work, our code must try really hard to complete, 
retrying at other server here, then at other city's or continent server room 
until its real task can be successfully done. Resources (eg. network services) 
needs to be acquired, then vetted, then operated on, then finally released in a 
consistent state. 

So we don't throw "something went wrong" (ie. unhandled exception) up. Nor we 
do "Return if any error". We do check errors, then
retry in loops. Go explicit, IN PLACE handling helps with that alot.

TC,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20210221005359.41b6f042%40xmint.

Re: [go-nuts] Error handling

[Michael MacInnis]

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 action. This 
wouldn't be difficult for you to add - just add a func() parameter to 
RecoverOn that is invoked when *err != nil. If you did that then we would 
both support performing actions whether an early return was triggered by 
check/ro.ReturnOn or a regular return with err set (assuming named return 
values).


I bind the check function (what you call ro.ReturnOn) to the error so that 
it can set that when passed a non-nil error. This allows check to be used 
directly, for example, on a function that only returns an error:

check(functionThatReturnsAnError())

Instead of having to do:

err = functionThatReturnsAnError()
ro.ReturnOn(err)

Binding the check and done functions means returning them both from a call 
to handle.Error. This adds one more line of code (defer done()) but means 
that check doesn't exist without this step and given that Go complains 
about unused variables it takes some work to forget to do something with 
done. My hope is that this significantly reduces the risk of an unhandled 
panic. (It's still possible to just call done and forget to defer it or 
name done _ so that the compiler won't complain, etc., etc.) As an added 
bonus people can call this pair of functions whatever they want 
(check/done, try/handle, ReturnOn/RecoverOn...). When I first posted I 
thought it would be neat to do:

check, handle := handle.Error // ...
so that the shadowing would make it impossible to call handle.Error again. 
But then I added Chain.

(It would be nice to get the handle.Errorf case down to one line but I 
haven't figured out a way to do that. Maybe something with how arguments to 
deferred function are evaluated but the function call itself isn't...)


In check I wrap the error in an unexported type:

type failure struct {
error
}

If this manages to slip by the idea is that it should be reported as an 
"unhandled error" plus the text of the actual error. It is the 
responsibility of done to unwrap the error and perform any actions on that. 
I'm paranoid about invoking recover, only invoke it when the error is the 
unexported failure type and even then check to make sure that the recovered 
value matches the error value. It is possible to always recover and then if 
we recover something we weren't supposed to, re-panic, but then we lose all 
the context for the original panic.


Looking back at the error handling problem outline I realized that I did 
not have the ability to add additional error handling actions. I added 
Chain a few days after my original post.


Michael.

On Saturday, February 20, 2021 at 4:21:10 PM UTC-5 michael...@gmail.com 
wrote:

> 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, 
> ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows:
>
> import "github.com/Michael-F-Ellis/ro" 
>
> func myfunc() (err error) { 
> defer ro.RecoverOn() 
>
> err = SomeFunctionCall() 
> ro.ReturnOn(err)
>
> // Do more stuff 
> // ... 
> return 
> }
>
> ReturnOn panics if err is not nil.
>
> RecoverOn recovers from the panic raised by ReturnOn and the function 
> exits with whatever error value would have been returned 
> normally. RecoverOn does not interfere with panics arising outside 
> of ReturnOn.
>
> Benefits and tradeoffs (coding discipline, debugging, performance) are 
> discussed in the README.
>
> Feedback welcomed either in this thread or in the repo issues.
>

-- 
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/87c73aa0-2ea2-4125-8cc9-3fe7972a4db9n%40googlegroups.com.

Re: [go-nuts] Error handling

[Robert Engels]

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 2:31 PM, Matthew Holiday  
> wrote:
> 
> 
> 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?
> 
> Yes, I suppose in some sense exceptions guarantee all errors are handled 
> somewhere. Unfortunately, what I've seen of exception handling over the years 
> is that it's often "log the stack trace and keep moving", which isn't all 
> that useful, and tends to cover up real bugs. A better approach would be not 
> to catch exceptions at all, and let them crash the program (which is what 
> Go's panic will do); this ensures the bugs are really handled by removing 
> them from the program.
> 
> [And given this type of exception "handling" it's not much value to the 
> author of a single function to know that the errors will all be "handled" 
> somewhere.]
> 
> Unfortunately, exception handling languages tend to put all types of errors, 
> normal and abnormal *, into the same basket. Which means you can't do 
> sensible error handling for, e.g., JSON that doesn't decode, while allowing 
> the program to crash when there's a logic bug. (For non-safety critical 
> software, a crash failure is typically the safest way to fail. 
> Safety-critical software, on the other hand, avoids exception handling like 
> the plague.)
> 
> * A normal error is some behavior that can reasonably be expected, such as 
> "file not found" or "no route to host", etc. Abnormal errors are logic bugs 
> in the program.
> 
> An aside:
> 
> Assuming you had a cyclomatic complexity calculator that took exceptions into 
> consideration, such that exceptions passing through a function counted as a 
> branch, what kind of numbers would you get? Probably pretty awful, given just 
> about any line of code would be capable of throwing an exception. But 
> exceptions typically aren't counted, so that functions are thought to be far 
> less complex than they really are in the presence of exceptions.
> 
> Invisible (magic) return paths through a function go against the notion of 
> "the code does what it says on the page".
> 
>> On Sat, Feb 20, 2021 at 1: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 is biggest difficult in reading (or using) others Go code. Exceptions 
>> (well written) handle this by declaring all possible error (or categories) 
>> thrown by the method. 
>> 
>> This seems a real problem with long term maintenance of Go code. 
>> 
 On Feb 20, 2021, at 1:39 PM, Matthew Holiday  
 wrote:
 
>>> 
>>> 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 
>>> "what keeps you from adopting Go?"
>>> (implying that the responders are those who haven't adopted Go)
>>> 
>>> Any type of error handling that creates invisible returns in a function is 
>>> a bad idea IMNSHO (an opinion backed up by various researches into the 
>>> complexity of exception handling). Speaking for myself, I'd like to retain 
>>> that quality of Go whereby "the code does exactly what it says on the page."
>>> 
>>> 
 On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:
 
 
> 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 major concern of Go users for a very 
> long time. 
 
 
 Actually the "guardians of Go" (by which I guess you mean the Go team at 
 Google) tried quite hard recently to propose an improved way of handling 
 errors, but it was resisted by "Go users". So what you're saying is just 
 not true, I'm afraid.
 
> 
> 
>> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>> 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 

Re: [go-nuts] Error handling

[Robert Engels]

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 difference between checked exceptions and Go’s error return in 
terms of responsibility - but exceptions are more easily enforced. 

When it comes to unchecked exceptions a lot depends on the use case. For 
instance, the consider an illegal state exception. Clearly a programming error, 
but how it is handled at higher levels depends... maybe roll back the current 
transaction and report an error to the caller, maybe crash the server? It all 
depends on the context , risk, capabilities - easier for higher layer to make 
this call than a low level function. Coupled with RAI you can create very 
robust and reliable systems. 

> On Feb 20, 2021, at 2:30 PM, Ian Lance Taylor  wrote:
> 
> 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 is biggest difficult in reading (or using) others Go code. Exceptions 
>> (well written) handle this by declaring all possible error (or categories) 
>> thrown by the method.
>> 
>> This seems a real problem with long term maintenance of Go code.
> 
> When you say that exceptions means declaring all possible errors
> thrown by the method, it seems to me that you are talking about
> checked exceptions.  There is pretty good evidence that real programs
> in practice do not list all possible error categories, even though
> ideally they should.  Instead, in practice, they fall back to
> unchecked exceptions.
> 
> So I think that your contrast to Go is an ideal that experience has
> shown is very difficult to achieve.  It's not an approach that leads
> to better long term maintenance in practice, even if it should in an
> ideal world.
> 
> (Incidentally, to answer the question in your first sentence directly,
> Go code does indeed do exactly what it shows on the page.  You are
> challenging that not by saying that it does something else, but by
> saying that that is not enough.)
> 
> Ian

-- 
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/D5D376CE-34D2-4575-94F4-CF899545F368%40ix.netcom.com.

Re: [go-nuts] Error handling

[Michael Ellis]

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, 
ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows:

import "github.com/Michael-F-Ellis/ro" 

func myfunc() (err error) { 
defer ro.RecoverOn() 

err = SomeFunctionCall() 
ro.ReturnOn(err)

// Do more stuff 
// ... 
return 
}

ReturnOn panics if err is not nil.

RecoverOn recovers from the panic raised by ReturnOn and the function exits 
with whatever error value would have been returned normally. RecoverOn does 
not interfere with panics arising outside of ReturnOn.

Benefits and tradeoffs (coding discipline, debugging, performance) are 
discussed in the README.

Feedback welcomed either in this thread or in the repo issues.

On Saturday, February 20, 2021 at 3:31:22 PM UTC-5 matthew...@nytimes.com 
wrote:

> 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?
>
> Yes, I suppose in some sense exceptions guarantee all errors are handled 
> somewhere. Unfortunately, what I've seen of exception handling over the 
> years is that it's often "log the stack trace and keep moving", which isn't 
> all that useful, and tends to cover up real bugs. A better approach would 
> be not to catch exceptions at all, and let them crash the program (which is 
> what Go's panic will do); this ensures the bugs are really handled by 
> removing them from the program.
>
> [And given this type of exception "handling" it's not much value to the 
> author of a single function to know that the errors will all be "handled" 
> somewhere.]
>
> Unfortunately, exception handling languages tend to put all types of 
> errors, normal and abnormal *, into the same basket. Which means you can't 
> do sensible error handling for, e.g., JSON that doesn't decode, while 
> allowing the program to crash when there's a logic bug. (For non-safety 
> critical software, a crash failure is typically the safest way to fail. 
> Safety-critical software, on the other hand, avoids exception handling like 
> the plague.)
>
> * A normal error is some behavior that can reasonably be expected, such as 
> "file not found" or "no route to host", etc. Abnormal errors are logic bugs 
> in the program.
>
> An aside:
>
> Assuming you had a cyclomatic complexity calculator that took exceptions 
> into consideration, such that exceptions passing through a function counted 
> as a branch, what kind of numbers would you get? Probably pretty awful, 
> given just about any line of code would be capable of throwing an 
> exception. But exceptions typically aren't counted, so that functions are 
> thought to be far less complex than they really are in the presence of 
> exceptions.
>
> Invisible (magic) return paths through a function go against the notion of 
> "the code does what it says on the page".
>
> On Sat, Feb 20, 2021 at 1: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 is biggest difficult in reading (or using) others Go 
>> code. Exceptions (well written) handle this by declaring all possible error 
>> (or categories) thrown by the method. 
>>
>> This seems a real problem with long term maintenance of Go code. 
>>
>> On Feb 20, 2021, at 1:39 PM, Matthew Holiday  
>> wrote:
>>
>> 
>> 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 "what keeps you from adopting Go?"
>> (implying that the responders are those who haven't adopted Go)
>>
>> Any type of error handling that creates invisible returns in a function 
>> is a bad idea IMNSHO (an opinion backed up by various researches into the 
>> complexity of exception handling). Speaking for myself, I'd like to retain 
>> that quality of Go whereby "the code does exactly what it says on the page."
>>
>>
>> On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:
>>
>>>
>>>
>>> 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 

Re: [go-nuts] Error handling

[Matthew Holiday]

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?

Yes, I suppose in some sense exceptions guarantee all errors are handled
somewhere. Unfortunately, what I've seen of exception handling over the
years is that it's often "log the stack trace and keep moving", which isn't
all that useful, and tends to cover up real bugs. A better approach would
be not to catch exceptions at all, and let them crash the program (which is
what Go's panic will do); this ensures the bugs are really handled by
removing them from the program.

[And given this type of exception "handling" it's not much value to the
author of a single function to know that the errors will all be "handled"
somewhere.]

Unfortunately, exception handling languages tend to put all types of
errors, normal and abnormal *, into the same basket. Which means you can't
do sensible error handling for, e.g., JSON that doesn't decode, while
allowing the program to crash when there's a logic bug. (For non-safety
critical software, a crash failure is typically the safest way to fail.
Safety-critical software, on the other hand, avoids exception handling like
the plague.)

* A normal error is some behavior that can reasonably be expected, such as
"file not found" or "no route to host", etc. Abnormal errors are logic bugs
in the program.

An aside:

Assuming you had a cyclomatic complexity calculator that took exceptions
into consideration, such that exceptions passing through a function counted
as a branch, what kind of numbers would you get? Probably pretty awful,
given just about any line of code would be capable of throwing an
exception. But exceptions typically aren't counted, so that functions are
thought to be far less complex than they really are in the presence of
exceptions.

Invisible (magic) return paths through a function go against the notion of
"the code does what it says on the page".

On Sat, Feb 20, 2021 at 1: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 is biggest difficult in reading (or using) others Go code. Exceptions
> (well written) handle this by declaring all possible error (or categories)
> thrown by the method.
>
> This seems a real problem with long term maintenance of Go code.
>
> On Feb 20, 2021, at 1:39 PM, Matthew Holiday 
> wrote:
>
> 
> 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 "what keeps you from adopting Go?"
> (implying that the responders are those who haven't adopted Go)
>
> Any type of error handling that creates invisible returns in a function is
> a bad idea IMNSHO (an opinion backed up by various researches into the
> complexity of exception handling). Speaking for myself, I'd like to retain
> that quality of Go whereby "the code does exactly what it says on the page."
>
>
> On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:
>
>>
>>
>> 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 major concern of Go users for a very long time.
>>
>>
>> Actually the "guardians of Go" (by which I guess you mean the Go team at
>> Google) tried quite hard recently to propose an improved way of handling
>> errors, but it was resisted by "Go users". So what you're saying is just
>> not true, I'm afraid.
>>
>>
>>>
>>> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>>>
 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 "boilerplate" than we were in languages where handling
 errors
 (failures) was "a problem of others", including future-us as "others".

 Perceived consensus of the Go community is that "error handling
 boilerplate"
 is a strong feature. I.e. in normal production software you MUST handle
 failures
 and you should do it as close as possible to the source of said
 failure.

 Go helps with that. Even team's 

Re: [go-nuts] Error handling

[Ian Lance Taylor]

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 
> is biggest difficult in reading (or using) others Go code. Exceptions (well 
> written) handle this by declaring all possible error (or categories) thrown 
> by the method.
>
> This seems a real problem with long term maintenance of Go code.

When you say that exceptions means declaring all possible errors
thrown by the method, it seems to me that you are talking about
checked exceptions.  There is pretty good evidence that real programs
in practice do not list all possible error categories, even though
ideally they should.  Instead, in practice, they fall back to
unchecked exceptions.

So I think that your contrast to Go is an ideal that experience has
shown is very difficult to achieve.  It's not an approach that leads
to better long term maintenance in practice, even if it should in an
ideal world.

(Incidentally, to answer the question in your first sentence directly,
Go code does indeed do exactly what it shows on the page.  You are
challenging that not by saying that it does something else, but by
saying that that is not enough.)

Ian

-- 
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/CAOyqgcWzfD%2BjjYQKHbu4R%3DxgtSoR_%3Duhp%3DmOEtqwKUvFJp7tWQ%40mail.gmail.com.

Re: [go-nuts] Error handling

[Robert Engels]

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. Exceptions (well 
written) handle this by declaring all possible error (or categories) thrown by 
the method. 

This seems a real problem with long term maintenance of Go code. 

> On Feb 20, 2021, at 1:39 PM, Matthew Holiday  
> wrote:
> 
> 
> 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 
> "what keeps you from adopting Go?"
> (implying that the responders are those who haven't adopted Go)
> 
> Any type of error handling that creates invisible returns in a function is a 
> bad idea IMNSHO (an opinion backed up by various researches into the 
> complexity of exception handling). Speaking for myself, I'd like to retain 
> that quality of Go whereby "the code does exactly what it says on the page."
> 
> 
>> On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:
>> 
>> 
>>> 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 major concern of Go users for a very long time. 
>> 
>> 
>> Actually the "guardians of Go" (by which I guess you mean the Go team at 
>> Google) tried quite hard recently to propose an improved way of handling 
>> errors, but it was resisted by "Go users". So what you're saying is just not 
>> true, I'm afraid.
>> 
>>> 
>>> 
 On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
 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 "boilerplate" than we were in languages where handling errors
 (failures) was "a problem of others", including future-us as "others". 
 
 Perceived consensus of the Go community is that "error handling 
 boilerplate" 
 is a strong feature. I.e. in normal production software you MUST handle 
 failures 
 and you should do it as close as possible to the source of said failure. 
 
 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.
 
 Error handling proposals umbrella: 
 https://github.com/golang/go/issues/40432 
 
 > Michael. 
 
 Hope this helps, 
 
 -- 
 Wojciech S. Czarnecki 
 << ^oo^ >> OHIR-RIPE 
>>> 
>>> -- 
>>> 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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com.
>> 
>> -- 
>> 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/CAJhgacim5uPaik2_QxgafB5uZ589ojWmbFdy54U6etHn4x5z0g%40mail.gmail.com.
> 
> 
> -- 
> Matt Holiday
> Senior Gopher, Marketing Technologies
> 
> 
> 620 Eighth Avenue
> New York, NY 10018
> matthew.holi...@nytimes.com
> -- 
> 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/CAGSa1C%3DyS48YXZ95ut_LaEiBU2MKCKF5pERgkW5q7%2BHVFv4Stw%40mail.gmail.com.

-- 
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/8A49E2C4-28FC-4777-8AD8-4FC4E6E2E347%40ix.netcom.com.

Re: [go-nuts] Error handling

[Matthew Holiday]

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
"what keeps you from adopting Go?"
(implying that the responders are those who haven't adopted Go)

Any type of error handling that creates invisible returns in a function is
a bad idea IMNSHO (an opinion backed up by various researches into the
complexity of exception handling). Speaking for myself, I'd like to retain
that quality of Go whereby "the code does exactly what it says on the page."


On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:

>
>
> 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 major concern of Go users for a very long time.
>
>
> Actually the "guardians of Go" (by which I guess you mean the Go team at
> Google) tried quite hard recently to propose an improved way of handling
> errors, but it was resisted by "Go users". So what you're saying is just
> not true, I'm afraid.
>
>
>>
>> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>>
>>> 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 "boilerplate" than we were in languages where handling
>>> errors
>>> (failures) was "a problem of others", including future-us as "others".
>>>
>>> Perceived consensus of the Go community is that "error handling
>>> boilerplate"
>>> is a strong feature. I.e. in normal production software you MUST handle
>>> failures
>>> and you should do it as close as possible to the source of said failure.
>>>
>>> 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.
>>>
>>> Error handling proposals umbrella:
>>> https://github.com/golang/go/issues/40432
>>>
>>> > Michael.
>>>
>>> Hope this helps,
>>>
>>> --
>>> Wojciech S. Czarnecki
>>> << ^oo^ >> OHIR-RIPE
>>>
>> --
>> 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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com
>> 
>> .
>>
> --
> 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/CAJhgacim5uPaik2_QxgafB5uZ589ojWmbFdy54U6etHn4x5z0g%40mail.gmail.com
> 
> .
>


-- 
*Matt Holiday*
Senior Gopher, Marketing Technologies

620 Eighth Avenue

New York, NY 10018

matthew.holi...@nytimes.com

-- 
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/CAGSa1C%3DyS48YXZ95ut_LaEiBU2MKCKF5pERgkW5q7%2BHVFv4Stw%40mail.gmail.com.

Re: [go-nuts] Error handling

[roger peppe]

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 major concern of Go users for a very long time.


Actually the "guardians of Go" (by which I guess you mean the Go team at
Google) tried quite hard recently to propose an improved way of handling
errors, but it was resisted by "Go users". So what you're saying is just
not true, I'm afraid.


>
> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>
>> 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 "boilerplate" than we were in languages where handling
>> errors
>> (failures) was "a problem of others", including future-us as "others".
>>
>> Perceived consensus of the Go community is that "error handling
>> boilerplate"
>> is a strong feature. I.e. in normal production software you MUST handle
>> failures
>> and you should do it as close as possible to the source of said failure.
>>
>> 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.
>>
>> Error handling proposals umbrella:
>> https://github.com/golang/go/issues/40432
>>
>> > Michael.
>>
>> Hope this helps,
>>
>> --
>> Wojciech S. Czarnecki
>> << ^oo^ >> OHIR-RIPE
>>
> --
> 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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com
> 
> .
>

-- 
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/CAJhgacim5uPaik2_QxgafB5uZ589ojWmbFdy54U6etHn4x5z0g%40mail.gmail.com.

Re: [go-nuts] Error handling

[L Godioleskky]

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 Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:

> 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 "boilerplate" than we were in languages where handling errors
> (failures) was "a problem of others", including future-us as "others".
>
> Perceived consensus of the Go community is that "error handling 
> boilerplate"
> is a strong feature. I.e. in normal production software you MUST handle 
> failures
> and you should do it as close as possible to the source of said failure.
>
> 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.
>
> Error handling proposals umbrella: 
> https://github.com/golang/go/issues/40432
>
> > Michael.
>
> Hope this helps,
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com.

Re: [go-nuts] Error handling

[robert engels]

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 paradigm for Go2.

> On Feb 18, 2021, at 6:01 PM, Michael MacInnis  
> wrote:
> 
> 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) (err error) {
> check, done := handle.Errorf(, "copy %s %s", src, dst);
> defer done()
> 
> r, err := os.Open(src); check(err)
> defer r.Close()
> 
> w, err := os.Create(dst); check(err)
> defer handle.Chain(, func() {
> w.Close()
> os.Remove(dst)
> })
> 
> _, err = io.Copy(w, r); check(err)
> return w.Close()
> }
> 
> looks pretty similar to this:
> 
> func CopyFile(src, dst string) error {
> handle err {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> 
> r := check os.Open(src)
> defer r.Close()
> 
> w := check os.Create(dst)
> handle err {
> w.Close()
> os.Remove(dst) // (only if a check fails)
> }
> 
> check io.Copy(w, r)
> check w.Close()
> return nil
> }
> 
> I'll probably continue playing with this. If others would like to take a look 
> the code is here:
> 
> https://github.com/michaelmacinnis/handle 
> 
> 
> I'm particularly interested in any problems I may have overlooked and similar 
> packages that may exist but that I haven't stumbled across.
> 
> Thanks,
> 
> Michael.
> 
> On Thursday, February 18, 2021 at 2:27:33 PM UTC-5 ren...@ix.netcom.com wrote:
> 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 AM, Kevin Chadwick  > > wrote: 
> > 
> >  
> >> 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 
> >> design/deliver/maintain. 
> >> 
> > 
> > I can't agree. Long lived go server processes are made of many single shot 
> > worker tasks that can send errors back just the same. 
> > 
> >> Exceptions (used properly) provide a lot of information when reading 
> >> the code. I don’t get the same feedback with Gos error returns. 
> > 
> > AFAICT, this is just structuring. There is nothing stopping your server 
> > processes from having a documented error processor, handling returned error 
> > types, possibly even from distributed services. 
> > 
> > The only real difference is if the errors are tunnelled in plain sight or 
> > behind the scenes. You could store rather than returning errors if you 
> > wanted to. I don't think Go users should be encouraged to hide errors away. 
> > 
> > -- 
> > 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/65F3B450-5507-4E3C-A09B-905DCF4C0006%40gmail.com
> >  
> > .
> >  
> 
> 
> -- 
> 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/1c510a2c-981b-4980-8f47-7a025769e233n%40googlegroups.com
>  
> .

-- 
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/3C6D4163-655A-47F2-B655-6D79D8B18BDC%40ix.netcom.com.

Re: [go-nuts] Error handling

[Michael MacInnis]

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) (err error) {
check, done := handle.Errorf(, "copy %s %s", src, dst);
defer done()

r, err := os.Open(src); check(err)
defer r.Close()

w, err := os.Create(dst); check(err)
defer handle.Chain(, func() {
w.Close()
os.Remove(dst)
})

_, err = io.Copy(w, r); check(err)
return w.Close()
}

looks pretty similar to this:

func CopyFile(src, dst string) error {
handle err {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

r := check os.Open(src)
defer r.Close()

w := check os.Create(dst)
handle err {
w.Close()
os.Remove(dst) // (only if a check fails)
}

check io.Copy(w, r)
check w.Close()
return nil
}

I'll probably continue playing with this. If others would like to take a 
look the code is here:

https://github.com/michaelmacinnis/handle

I'm particularly interested in any problems I may have overlooked and 
similar packages that may exist but that I haven't stumbled across.

Thanks,

Michael.

On Thursday, February 18, 2021 at 2:27:33 PM UTC-5 ren...@ix.netcom.com 
wrote:

> 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 AM, Kevin Chadwick  wrote:
> > 
> > 
> >> 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
> >> design/deliver/maintain.
> >> 
> > 
> > I can't agree. Long lived go server processes are made of many single 
> shot worker tasks that can send errors back just the same.
> > 
> >> Exceptions (used properly) provide a lot of information when reading
> >> the code. I don’t get the same feedback with Gos error returns. 
> > 
> > AFAICT, this is just structuring. There is nothing stopping your server 
> processes from having a documented error processor, handling returned error 
> types, possibly even from distributed services.
> > 
> > The only real difference is if the errors are tunnelled in plain sight 
> or behind the scenes. You could store rather than returning errors if you 
> wanted to. I don't think Go users should be encouraged to hide errors away.
> > 
> > -- 
> > 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/65F3B450-5507-4E3C-A09B-905DCF4C0006%40gmail.com
> .
>
>

-- 
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/1c510a2c-981b-4980-8f47-7a025769e233n%40googlegroups.com.

Re: [go-nuts] Error handling

[Robert Engels]

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 AM, Kevin Chadwick  wrote:
> 
> 
>> 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
>> design/deliver/maintain.
>> 
> 
> I can't agree. Long lived go server processes are made of many single shot 
> worker tasks that can send errors back just the same.
> 
>> Exceptions (used properly) provide a lot of information when reading
>> the code.  I don’t get the same feedback with Gos error returns. 
> 
> AFAICT, this is just structuring. There is nothing stopping your server 
> processes from having a documented error processor, handling returned error 
> types, possibly even from distributed services.
> 
> The only real difference is if the errors are tunnelled in plain sight or 
> behind the scenes. You could store rather than returning errors if you wanted 
> to. I don't think Go users should be encouraged to hide errors away.
> 
> -- 
> 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/65F3B450-5507-4E3C-A09B-905DCF4C0006%40gmail.com.

-- 
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/32EB0DA8-A814-44D1-A62E-E0610B08C254%40ix.netcom.com.

Re: [go-nuts] Error handling

[Kevin Chadwick]

 
>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
>design/deliver/maintain.
>

I can't agree. Long lived go server processes are made of many single shot 
worker tasks that can send errors back just the same.

>Exceptions (used properly) provide a lot of information when reading
>the code.  I don’t get the same feedback with Gos error returns. 

AFAICT, this is just structuring. There is nothing stopping your server 
processes from having a documented error processor, handling returned error 
types, possibly even from distributed services.

The only real difference is if the errors are tunnelled in plain sight or 
behind the scenes. You could store rather than returning errors if you wanted 
to. I don't think Go users should be encouraged to hide errors away.

-- 
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/65F3B450-5507-4E3C-A09B-905DCF4C0006%40gmail.com.

Re: [go-nuts] Error handling

[Robert Engels]

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 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 design/deliver/maintain.

Exceptions (used properly) provide a lot of information when reading the code.  
I don’t get the same feedback with Gos error returns. 

> On Feb 18, 2021, at 5:13 AM, 'Carla Pfaff' via golang-nuts 
>  wrote:
> 
> 
>> 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 made another proposal, the "try" 
> proposal, but it was rejected as well. Now error handling is on the 
> back-burner and they are focusing on generics:
> https://github.com/golang/go/issues/32437#issuecomment-513002788
> "Also, realistically, since we don't have unlimited resources, I see thinking 
> about language support for error handling go on the back-burner for a bit in 
> favor of more progress on other fronts, most notably work on generics"
> 
> -- 
> 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/c60af668-55d6-4977-a746-b04dbc67e31an%40googlegroups.com.

-- 
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/FA07FB86-4563-46BA-8885-F94C95E6141E%40ix.netcom.com.

Re: [go-nuts] Error handling

['Carla Pfaff' via golang-nuts]

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 made another proposal, the "try" 
proposal, but it was rejected as well. Now error handling is on the 
back-burner and they are focusing on generics:
https://github.com/golang/go/issues/32437#issuecomment-513002788
"Also, realistically, since we don't have unlimited resources, I see 
thinking about language support for error handling go on the back-burner 
for a bit in favor of more progress on other fronts, most notably work on 
generics"

-- 
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/c60af668-55d6-4977-a746-b04dbc67e31an%40googlegroups.com.

Re: [go-nuts] Error handling

[Kevin Chadwick]

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 handle it.

Occasionally I think what could I add here at the points that you call
boilerplate. However, I almost always add context at every level. The benefit is
that I hardly ever have to pull out a debugger or even read the code aside from
the failure point or stdlib code. The debugger is useful for more subtle issues,
but a big, time waste, most of the time.

You can also create test errors easily by wrapping with the recent changes.
Wrapped errors act, in a way like exceptions. In fact, I log the latest
test/wrapped error and any previous one in the chain. So that I may see any one
provided by the stdlib as well as my own.

What you are proposing doesn't match up with Gos ease of picking up and running
with the language with good outcomes because exceptions are less likely to be
handled than errors by most devs and also in most situations. It also doesn't
marry up with the policy of trying to keep one way of doing things, for similar
reasons. Isn't there a package, that you could use?

-- 
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/a4f5ba51-c704-9616-a8b9-c6a0bbad1bab%40gmail.com.

Re: [go-nuts] Error handling

[Brian Candler]

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 to 
start up (Kafka CLI for example); Go tools are more like 5ms in my 
experience, thanks to being compiled ahead-of-time into native code.  So I 
don't think that's a fair comparison.

I think we may be discussing a different use case here.  In the Unix world, 
if you want something to be resilient against a total process crash, then 
you spawn it as a child, you supervise it, and restart it if necessary.  
What you get back is not so much an exception, as an exit code.

Among programming languages, the one I can think of with a similar concept 
is Erlang, which provides for a process supervision tree.  Erlang processes 
 are the equivalent 
of goroutines.  A process terminates with an exit reason 
.  
You can link  
related processes together.  Patterns in go which provide for similar 
supervision trees of goroutines would be an interesting area of study.  
(Note that in Erlang you tend to use processes for more than just 
concurrency. There is no variable rebinding, so you need a function to call 
itself recursively to model mutable state: so you stick that function in a 
process and send messages to it)

However, I think the types of errors being discussed in this thread are 
just part of sequential code operation.  For example, when you open a file:
* it may be successful, you get back a file handle
* there may be a "normal" failure because of user-supplied data, e.g. "a 
file with that name does not exist"
* there may be a "system" failure, e.g. "I/O error on disk"

When you read from the open file, similarly there are other errors: e.g. "I 
expected that file to contain valid JSON, but it doesn't".  These cases 
need to be distinguished and handled somewhere.

-- 
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/08ab4673-ae1c-4f24-9890-0805ed4f4dd8n%40googlegroups.com.

Re: [go-nuts] Error handling

[Amnon]

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 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/36fc8b38-9c82-41a2-a8df-31ac66aeaff5n%40googlegroups.com.

Re: [go-nuts] Error handling

[Miguel Angel Rivera Notararigo]

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

Re: [go-nuts] Error handling

[robert engels]

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 at least codified, and with GC/RAI the 
system with try/finally can have a coherent view of the current state. You can 
do this with Go, but it is not “easy” by any means. Exceptions force the error 
handling up the stack until the layer is capable of handling it.

Go - whether people like this or not - is VERY close to Java (because of the 
“runtime”) - and both suffer from “runtime overhead/startup cost” - so Go 
processes become “servers”. Writing resilient user space servers is difficult 
in Java and more so in Go due to the lack of exceptions.

Beyond error handling, Go (and Java) are weak in resource management - which 
opens another door of bugs/problems related to “user space OS”.

Every OS has exceptions - i.e. process failure due to unforeseen reasons.

There are other tactical problems that exceptions solve that error returns do 
not. Think of a complex multi-component system - and a module decides to expose 
a new “class of errors” - with exceptions you can force existing well-written 
code to break at compile time (unknown exception in the hierarchy), with error 
returns this is not possible (at least not in Go with non-standardized error 
“classes”). Any there are many similar problems.

These are all issues C programmers struggled with for years - and why error 
handling was changed in C++.


> On Feb 17, 2021, at 9:42 PM, Henry  wrote:
> 
> 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 1:46:07 AM UTC+7 skinne...@gmail.com 
>  wrote:
> 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 our training. The discreet patterns I use are:
> Handle errors that can be handled close to where they occur.
> Report errors that cannot be handled because they were caused by the calling 
> function passing a bad parameter.
> Panic on errors that prevent a function that MustComplete from completing 
> because they cannot be handled. 
> Try a MustComplete() with recover from the panic that reports to the User and 
> or Developer the nature of the problem and how to resolve it manually or at 
> least add it to issues.
> Ensure that no matter what happens, you do not corrupt the HDD, lockup the 
> hardware, CTD, or leave unexpected artefacts on the screen.
> There is no one best way of dealing with errors but there are patterns for 
> dealing with errors, if you only learn one pattern then you will not be 
> writing good code (if you only have a hammer, everything looks like a nail).
> 
> Golang does not have error patterns that are clear and distinct for novice 
> programmers and it does not inhibit advanced programmers from dealing with 
> errors in whatever way they think appropriate.
> 
> A useful abstraction would be to simplify the error handling by 
> identification of the type of pattern desired and use the most concise and 
> yet easily understood way of writing it. Go has tools in place to allow each 
> user to create a preprocessor for error handling or any other purpose but it 
> would be nice if we were all on the same page.
> 
> On Monday, February 15, 2021 at 12:53:43 PM UTC-6 ren...@ix.netcom.com 
>  wrote:
> 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 
> point. For complex server long-lived processes, exception handling makes it 
> much easier to design and deliver secure fault tolerant systems. Resilient 
> Unix relies on the ability to start new processes to handle requests, track 
> DoS attacks, faulty clients, etc. Process termination is a part of this. The 
> Go runtime does not fit this model, so it needs to replicate it.
> 
> People write bad exception code - people write bad error return code. It’s 
> easier to write and maintain good exception code. To this day, very few major 
> systems are written in Go - at some point we have to ask honestly why - I 
> think Go’s  error handling is an important factor here.
> 
> Go can probably get there without exceptions, but it entails standardized 
> error 

Re: [go-nuts] Error handling

[Henry]

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 1:46:07 AM UTC+7 skinne...@gmail.com 
wrote:

> 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 our training. The discreet patterns I use are:
>
>- Handle errors that can be handled close to where they occur.
>- Report errors that cannot be handled because they were caused by the 
>calling function passing a bad parameter.
>- Panic on errors that prevent a function that MustComplete from 
>completing because they cannot be handled. 
>- Try a MustComplete() with recover from the panic that reports to the 
>User and or Developer the nature of the problem and how to resolve it 
>manually or at least add it to issues.
>- Ensure that no matter what happens, you do not corrupt the HDD, 
>lockup the hardware, CTD, or leave unexpected artefacts on the screen.
>
> There is no one best way of dealing with errors but there are patterns for 
> dealing with errors, if you only learn one pattern then you will not be 
> writing good code (if you only have a hammer, everything looks like a nail).
>
> Golang does not have error patterns that are clear and distinct for novice 
> programmers and it does not inhibit advanced programmers from dealing with 
> errors in whatever way they think appropriate.
>
> A useful abstraction would be to simplify the error handling by 
> identification of the type of pattern desired and use the most concise and 
> yet easily understood way of writing it. Go has tools in place to allow 
> each user to create a preprocessor for error handling or any other purpose 
> but it would be nice if we were all on the same page.
>
> On Monday, February 15, 2021 at 12:53:43 PM UTC-6 ren...@ix.netcom.com 
> wrote:
>
>> 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 
>> point. For complex server long-lived processes, exception handling makes it 
>> much easier to design and deliver secure fault tolerant systems. Resilient 
>> Unix relies on the ability to start new processes to handle requests, track 
>> DoS attacks, faulty clients, etc. Process termination is a part of this. 
>> The Go runtime does not fit this model, so it needs to replicate it.
>>
>> People write bad exception code - people write bad error return code. 
>> It’s easier to write and maintain good exception code. To this day, very 
>> few major systems are written in Go - at some point we have to ask honestly 
>> why - I think Go’s  error handling is an important factor here.
>>
>> Go can probably get there without exceptions, but it entails standardized 
>> error declarations, wrapping, inspection, logging, etc. I think the Go2 
>> error handling proposals attempt this.
>>
>> On Feb 15, 2021, at 11:25 AM, Volker Dobler  
>> wrote:
>>
>> 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 a point where 
>> they are unwilling to even try the language. How much their expertise 
>> counts if they never really worked with proper error handling in Go is 
>> debatable. Having worked with error returns and exceptions I can tell you 
>> that proper error handling with exceptions is much more painful than with 
>> errors. But of course: If your infrastructure, your business requirements 
>> and your acceptance criteria allow for making any problem a problem of 
>> someone else than exceptions are godsend.
>>
>> V.
>>
>> On Sunday, 14 February 2021 at 17:41:18 UTC+1 ren...@ix.netcom.com wrote:
>>
>>> 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: 
>>> > 
>>> > 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 

Re: [go-nuts] Error handling

[David Skinner]

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 our training. The discreet patterns I use are:

   - Handle errors that can be handled close to where they occur.
   - Report errors that cannot be handled because they were caused by the 
   calling function passing a bad parameter.
   - Panic on errors that prevent a function that MustComplete from 
   completing because they cannot be handled. 
   - Try a MustComplete() with recover from the panic that reports to the 
   User and or Developer the nature of the problem and how to resolve it 
   manually or at least add it to issues.
   - Ensure that no matter what happens, you do not corrupt the HDD, lockup 
   the hardware, CTD, or leave unexpected artefacts on the screen.

There is no one best way of dealing with errors but there are patterns for 
dealing with errors, if you only learn one pattern then you will not be 
writing good code (if you only have a hammer, everything looks like a nail).

Golang does not have error patterns that are clear and distinct for novice 
programmers and it does not inhibit advanced programmers from dealing with 
errors in whatever way they think appropriate.

A useful abstraction would be to simplify the error handling by 
identification of the type of pattern desired and use the most concise and 
yet easily understood way of writing it. Go has tools in place to allow 
each user to create a preprocessor for error handling or any other purpose 
but it would be nice if we were all on the same page.

On Monday, February 15, 2021 at 12:53:43 PM UTC-6 ren...@ix.netcom.com 
wrote:

> 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 
> point. For complex server long-lived processes, exception handling makes it 
> much easier to design and deliver secure fault tolerant systems. Resilient 
> Unix relies on the ability to start new processes to handle requests, track 
> DoS attacks, faulty clients, etc. Process termination is a part of this. 
> The Go runtime does not fit this model, so it needs to replicate it.
>
> People write bad exception code - people write bad error return code. It’s 
> easier to write and maintain good exception code. To this day, very few 
> major systems are written in Go - at some point we have to ask honestly why 
> - I think Go’s  error handling is an important factor here.
>
> Go can probably get there without exceptions, but it entails standardized 
> error declarations, wrapping, inspection, logging, etc. I think the Go2 
> error handling proposals attempt this.
>
> On Feb 15, 2021, at 11:25 AM, Volker Dobler  wrote:
>
> 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 a point where 
> they are unwilling to even try the language. How much their expertise 
> counts if they never really worked with proper error handling in Go is 
> debatable. Having worked with error returns and exceptions I can tell you 
> that proper error handling with exceptions is much more painful than with 
> errors. But of course: If your infrastructure, your business requirements 
> and your acceptance criteria allow for making any problem a problem of 
> someone else than exceptions are godsend.
>
> V.
>
> On Sunday, 14 February 2021 at 17:41:18 UTC+1 ren...@ix.netcom.com wrote:
>
>> 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: 
>> > 
>> > 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 "boilerplate" than we were in languages where handling 
>> errors 
>> > (failures) was "a problem of others", including future-us as "others". 
>> > 
>> > Perceived consensus of the Go community is that "error handling 
>> boilerplate" 
>> > is a strong feature. I.e. in normal production software you MUST handle 
>> failures 
>> > and you should 

Re: [go-nuts] Error handling

[robert engels]

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 point. For 
complex server long-lived processes, exception handling makes it much easier to 
design and deliver secure fault tolerant systems. Resilient Unix relies on the 
ability to start new processes to handle requests, track DoS attacks, faulty 
clients, etc. Process termination is a part of this. The Go runtime does not 
fit this model, so it needs to replicate it.

People write bad exception code - people write bad error return code. It’s 
easier to write and maintain good exception code. To this day, very few major 
systems are written in Go - at some point we have to ask honestly why - I think 
Go’s  error handling is an important factor here.

Go can probably get there without exceptions, but it entails standardized error 
declarations, wrapping, inspection, logging, etc. I think the Go2 error 
handling proposals attempt this.

> On Feb 15, 2021, at 11:25 AM, Volker Dobler  
> wrote:
> 
> 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 a point where 
> they are unwilling to even try the language. How much their expertise counts 
> if they never really worked with proper error handling in Go is debatable. 
> Having worked with error returns and exceptions I can tell you that proper 
> error handling with exceptions is much more painful than with errors. But of 
> course: If your infrastructure, your business requirements and your 
> acceptance criteria allow for making any problem a problem of someone else 
> than exceptions are godsend.
> 
> V.
> 
> On Sunday, 14 February 2021 at 17:41:18 UTC+1 ren...@ix.netcom.com wrote:
> 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: 
> > 
> > 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 "boilerplate" than we were in languages where handling errors 
> > (failures) was "a problem of others", including future-us as "others". 
> > 
> > Perceived consensus of the Go community is that "error handling 
> > boilerplate" 
> > is a strong feature. I.e. in normal production software you MUST handle 
> > failures 
> > and you should do it as close as possible to the source of said failure. 
> > 
> > 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. 
> > 
> > Error handling proposals umbrella: 
> > https://github.com/golang/go/issues/40432 
> >  
> > 
> >> Michael. 
> > 
> > Hope this helps, 
> > 
> > -- 
> > Wojciech S. Czarnecki 
> > << ^oo^ >> OHIR-RIPE 
> > 
> > -- 
> > 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/20210214171250.4377c454%40xmint
> >  
> > .
> >  
> 
> 
> -- 
> 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/d9cdb32d-2609-4ae9-a9ff-36830c877245n%40googlegroups.com
>  
> .

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

[Arnaud Delobelle]

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 {
return err
}

// ...
}

// PWrapf applies Wrapf to an error pointer
func PWrapf(err *error, format string, args ...interface{}) {
*err = errors.Wrapf(*err, format, args...)
}

On Sun, 14 Feb 2021 at 01:45, Michael MacInnis
 wrote:
>
> 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 := handle.Errorf(, "do(%s)", name); defer handle()
>
> s, err := works(name); check(err)
>
> // ...
> }
>
> Other than the named return value and check being a hidden return, are there 
> reasons I would want to avoid doing this? I assume others have tried similar 
> things but I haven't stumbled across any similar packages.
>
> Before using it in production I would probably want a linter that checks to 
> make sure that the statement after handle.Error or handle.Errorf is defer 
> blah, where blah is the name given to the second value returned by those 
> functions and that all of this happens at the start of a function.
>
> Michael.
>
> --
> 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/cbe53d07-4f99-49fa-a708-dcb85b1aff5bn%40googlegroups.com.

-- 
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/CAJ6cK1ZgvpGV_vUFwHc%2BbadJXcoJO%3Dwv4-tfaWTYqjQbM%2BOMMg%40mail.gmail.com.

Re: [go-nuts] Error handling

[Volker Dobler]

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 a point where 
they are unwilling to even try the language. How much their expertise 
counts if they never really worked with proper error handling in Go is 
debatable. Having worked with error returns and exceptions I can tell you 
that proper error handling with exceptions is much more painful than with 
errors. But of course: If your infrastructure, your business requirements 
and your acceptance criteria allow for making any problem a problem of 
someone else than exceptions are godsend.

V.

On Sunday, 14 February 2021 at 17:41:18 UTC+1 ren...@ix.netcom.com wrote:

> 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:
> > 
> > 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 "boilerplate" than we were in languages where handling 
> errors
> > (failures) was "a problem of others", including future-us as "others".
> > 
> > Perceived consensus of the Go community is that "error handling 
> boilerplate"
> > is a strong feature. I.e. in normal production software you MUST handle 
> failures
> > and you should do it as close as possible to the source of said failure.
> > 
> > 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.
> > 
> > Error handling proposals umbrella: 
> https://github.com/golang/go/issues/40432
> > 
> >> Michael.
> > 
> > Hope this helps,
> > 
> > -- 
> > Wojciech S. Czarnecki
> > << ^oo^ >> OHIR-RIPE
> > 
> > -- 
> > 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/20210214171250.4377c454%40xmint
> .
>
>

-- 
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/d9cdb32d-2609-4ae9-a9ff-36830c877245n%40googlegroups.com.

Re: [go-nuts] Error handling

[Michael MacInnis]

>
> 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 check/handle proposal.

I agree that handling errors, and doing so close to where they occur, is a 
good thing. I also agree with the goals as outlined in the error handling 
problem statement. Specifically, that it would be nice if it was possible 
to make "error checks more lightweight, reducing the amount of Go program 
text dedicated to error checking". But that in doing so "error checks and 
error handling must remain explicit".

What I find interesting is how close we can get to something resembling try 
or check/handle with existing constructs.

While

f, err := os.Open(filename); check(err)
is not as terse as

f := try(os.Open(filename))

there is less much less text dedicated to error checking than with

f, err := os.Open(filename)
if err != nil {
// Handle err.
}

and passing err explicitly also means there isn't something to unwrap when 
debugging (to get to err) which I thought was an interesting objection to 
try.

Similarly, while

check, handle := handle.Errorf(, "copy %s %s", src, dst)
defer handle()

requires the enclosing function to use named return values and is not as 
terse as

handle err {
fmt.Errorf("copy %s %s: %v", src, dst, err)
}

it is close to the suggestion for decorating errors in the try proposal

defer fmt.HandleErrorf(, "copy %s %s", src, dst)

The problem is that forgetting to defer handle (in my version) means that 
check will cause an unrecovered panic. I'm also wondering if there are 
other interactions that I've overlooked. It is these more mechanism than 
policy considerations where I'm looking for feedback.

Michael.

-- 
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/f6673e29-1366-476a-8fcc-31f6a4efe22dn%40googlegroups.com.

Re: [go-nuts] Error handling

[robert engels]

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:
> 
> 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 "boilerplate" than we were in languages where handling errors
> (failures) was "a problem of others", including future-us as "others".
> 
> Perceived consensus of the Go community is that "error handling boilerplate"
> is a strong feature. I.e. in normal production software you MUST handle 
> failures
> and you should do it as close as possible to the source of said failure.
> 
> 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.
> 
> Error handling proposals umbrella: https://github.com/golang/go/issues/40432
> 
>> Michael.
> 
> Hope this helps,
> 
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
> 
> -- 
> 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/20210214171250.4377c454%40xmint.

-- 
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/B2B2509D-8FD5-4F3D-B469-080E3498D5F1%40ix.netcom.com.

Re: [go-nuts] Error handling

[Wojciech S. Czarnecki]

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 "boilerplate" than we were in languages where handling errors
(failures) was "a problem of others", including future-us as "others".

Perceived consensus of the Go community is that "error handling boilerplate"
is a strong feature. I.e. in normal production software you MUST handle failures
and you should do it as close as possible to the source of said failure.

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.

Error handling proposals umbrella: https://github.com/golang/go/issues/40432

> Michael.

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20210214171250.4377c454%40xmint.

Re: [go-nuts] error handling proposals summary

[Ian Lance Taylor]

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: 
> https://seankhliao.com/blog/12020-11-23-go-error-handling-proposals/

Thanks for doing that.  I added a note at https://golang.org/issue/40432.

Ian

-- 
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/CAOyqgcWLgN4JgNmd22ochYTLd_YUrZjStaxYqixuO%2BpU93e2JQ%40mail.gmail.com.

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

[Kaveh Shahbazian]

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 the error is not nil.

The concept is similar to piping functions - which Go already has a nice 
form of it.

This approach is far more restricted and removes only the if someError != 
nil part. So there is much less room for "creativity".

*It enforces following early return technique/pattern*. Which leads to more 
clear code.

For anything more complicated (in terms of conditions for handling the 
error), we have to write the more complicated solution.

On Thursday, July 30, 2020 at 5:46:39 AM UTC+2 Ian Lance Taylor wrote:

> 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 special construct.
> >
> > Now, assume we have a function named funcCtx:
> >
> > func funcCtx() (res int, err error) {
> > // ...
> > }
> >
> > Having that, these does not look that ugly:
> >
> > func funcCtx() (res int, err error) {
> > res, return() = action()
> > // or
> > res, panic() = action()
> > }
> >
> > Those statements will have an effect, only if the returned value is not 
> nil. For performing some actions, before the actual return or panic:
> >
> > res, return({ log.Println(err) }) = action()
> >
> > There is this restriction, that the function that contains this block, 
> funcCtx, has to return named return values - for both handling the zero 
> values and having a one to one mapping between its return values and those 
> of action function.
> >
> > Also for having a name, err in this case, that makes it clear, which 
> variable we are talking about.
> >
> > In the proposal, it's not clear where the err variable comes from (what 
> if there are three return values?)
>
> Thanks. This idea seems somewhat similar to https://golang.org/issue/27519
> .
>
> Ian
>

-- 
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/23f3c2e6-1f4e-4370-8212-5faaecb28c42n%40googlegroups.com.

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

[Ian Lance Taylor]

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 
> special construct.
>
> Now, assume we have a function named funcCtx:
>
> func funcCtx() (res int, err error) {
> // ...
> }
>
> Having that, these does not look that ugly:
>
> func funcCtx() (res int, err error) {
> res, return() = action()
> // or
> res, panic() = action()
> }
>
> Those statements will have an effect, only if the returned value is not nil. 
> For performing some actions, before the actual return or panic:
>
> res, return({ log.Println(err) }) = action()
>
> There is this restriction, that the function that contains this block, 
> funcCtx, has to return named return values - for both handling the zero 
> values and having a one to one mapping between its return values and those of 
> action function.
>
> Also for having a name, err in this case, that makes it clear, which variable 
> we are talking about.
>
> In the proposal, it's not clear where the err variable comes from (what if 
> there are three return values?)

Thanks.  This idea seems somewhat similar to https://golang.org/issue/27519.

Ian

-- 
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/CAOyqgcXg1E6aNpcLu%2BFNSwg2GkLZQ0YLeKe2yvwUVuYyx9QVpg%40mail.gmail.com.

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

[Ian Lance Taylor]

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 receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

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 features the original designers left out intentionally, rather than 
deciding that Go is not suitable for this application and use something else.

People get overly invested in tools. Yes, your learning time and job prospects 
make this investment bilateral. Still, if you stop doing engineering and 
instead just use the tool you’ve backed you’re bound to fail. 

Sent from my iPhone

> On Oct 8, 2018, at 11:10 PM, Robert Engels  wrote:
> 
> I’m sorry you feel that way. None of my comments on Go were intended to be 
> abrasive, they were intended to be matter of fact. 
> 
> You are mistaken as well if you think I was proposing exceptions as any sort 
> of silver bullet. They address the exact concerns the OP had. Exceptions also 
> come with more structure and “process” which can be a negative in some 
> environments. Thus the trade offs I referenced.  
> 
> You can have simple or you can have robust. You can’t have both, but which is 
> needed is determined by the problem at hand. 
> 
> Sent from my iPhone
> 
>> On Oct 8, 2018, at 10:46 PM, Dan Kortschak  
>> wrote:
>> 
>> OK, I'll have to accept that.
>> 
>> However, in your reply that I responded to you wrote:
>> 
>>> But to each his own, just please don’t work on anything with critical
>>> safety issues please. Thanks for your understanding.
>> 
>> This was rude.
>> 
>> Further, to explain my original post. It is a joke talking about
>> people, by stealth changing one language to another because the
>> destination is the Obviously Correct™ language to use. This struck a
>> chord with my with your claims about things that are obviously missing
>> from Go that are present in Java and how we as a community in Go should
>> just stop fooling around and start doing it the Right Way™.
>> 
>> ISTM that in your comment "Yes, lobby to have Go2 include exceptions
>> and then you don’t need to worry about any of this... :)" you are
>> indeed suggesting that the actually is a silver bullet, and that Java
>> has it and that Go doesn't. It may be the case that I have
>> misinterpreted what you wrote (the smiley supports this), but the
>> fairly consistent abrasiveness of you posts regarding deficits in Go
>> that Java has already solved suggests to me on balance that I haven't.
>> If I have, I apologise.
>> 
>> I have nothing further to add to this thread.
>> 
>> Dan
>> 
>>> On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote:
>>> I was only speaking for James Gosling. Engineering is balancing trade
>>> offs, which usually entails choosing the proper tools and processes
>>> for the task at hand. 
>>> 
>>> There are no silver bullets and taking positions that hinge on them
>>> is a fools errand. 
>>> 
>>> Sent from my iPhone
>>> 
 
 On Oct 8, 2018, at 8:23 PM, Dan Kortschak >>> du.au> wrote:
 
 That is uncalled for.
 
 Dan
 
> 
> On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote:
> I don’t think denigrating the most obvious advancement in
> computer
> software in the last 20 years helps move things forward.
> 
> But to each his own, just please don’t work on anything with
> critical
> safety issues please. Thanks for your understanding.
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

I’m sorry you feel that way. None of my comments on Go were intended to be 
abrasive, they were intended to be matter of fact. 

You are mistaken as well if you think I was proposing exceptions as any sort of 
silver bullet. They address the exact concerns the OP had. Exceptions also come 
with more structure and “process” which can be a negative in some environments. 
Thus the trade offs I referenced.  

You can have simple or you can have robust. You can’t have both, but which is 
needed is determined by the problem at hand. 

Sent from my iPhone

> On Oct 8, 2018, at 10:46 PM, Dan Kortschak  
> wrote:
> 
> OK, I'll have to accept that.
> 
> However, in your reply that I responded to you wrote:
> 
>> But to each his own, just please don’t work on anything with critical
>> safety issues please. Thanks for your understanding.
> 
> This was rude.
> 
> Further, to explain my original post. It is a joke talking about
> people, by stealth changing one language to another because the
> destination is the Obviously Correct™ language to use. This struck a
> chord with my with your claims about things that are obviously missing
> from Go that are present in Java and how we as a community in Go should
> just stop fooling around and start doing it the Right Way™.
> 
> ISTM that in your comment "Yes, lobby to have Go2 include exceptions
> and then you don’t need to worry about any of this... :)" you are
> indeed suggesting that the actually is a silver bullet, and that Java
> has it and that Go doesn't. It may be the case that I have
> misinterpreted what you wrote (the smiley supports this), but the
> fairly consistent abrasiveness of you posts regarding deficits in Go
> that Java has already solved suggests to me on balance that I haven't.
> If I have, I apologise.
> 
> I have nothing further to add to this thread.
> 
> Dan
> 
>> On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote:
>> I was only speaking for James Gosling. Engineering is balancing trade
>> offs, which usually entails choosing the proper tools and processes
>> for the task at hand. 
>> 
>> There are no silver bullets and taking positions that hinge on them
>> is a fools errand. 
>> 
>> Sent from my iPhone
>> 
>>> 
>>> On Oct 8, 2018, at 8:23 PM, Dan Kortschak >> du.au> wrote:
>>> 
>>> That is uncalled for.
>>> 
>>> Dan
>>> 
 
 On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote:
 I don’t think denigrating the most obvious advancement in
 computer
 software in the last 20 years helps move things forward.
 
 But to each his own, just please don’t work on anything with
 critical
 safety issues please. Thanks for your understanding.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[Dan Kortschak]

OK, I'll have to accept that.

However, in your reply that I responded to you wrote:

> But to each his own, just please don’t work on anything with critical
> safety issues please. Thanks for your understanding.

This was rude.

Further, to explain my original post. It is a joke talking about
people, by stealth changing one language to another because the
destination is the Obviously Correct™ language to use. This struck a
chord with my with your claims about things that are obviously missing
from Go that are present in Java and how we as a community in Go should
just stop fooling around and start doing it the Right Way™.

ISTM that in your comment "Yes, lobby to have Go2 include exceptions
and then you don’t need to worry about any of this... :)" you are
indeed suggesting that the actually is a silver bullet, and that Java
has it and that Go doesn't. It may be the case that I have
misinterpreted what you wrote (the smiley supports this), but the
fairly consistent abrasiveness of you posts regarding deficits in Go
that Java has already solved suggests to me on balance that I haven't.
If I have, I apologise.

I have nothing further to add to this thread.

Dan

On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote:
> I was only speaking for James Gosling. Engineering is balancing trade
> offs, which usually entails choosing the proper tools and processes
> for the task at hand. 
> 
> There are no silver bullets and taking positions that hinge on them
> is a fools errand. 
> 
> Sent from my iPhone
> 
> > 
> > On Oct 8, 2018, at 8:23 PM, Dan Kortschak  > du.au> wrote:
> > 
> > That is uncalled for.
> > 
> > Dan
> > 
> > > 
> > > On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote:
> > > I don’t think denigrating the most obvious advancement in
> > > computer
> > > software in the last 20 years helps move things forward.
> > > 
> > > But to each his own, just please don’t work on anything with
> > > critical
> > > safety issues please. Thanks for your understanding.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

I was only speaking for James Gosling. Engineering is balancing trade offs, 
which usually entails choosing the proper tools and processes for the task at 
hand. 

There are no silver bullets and taking positions that hinge on them is a fools 
errand. 

Sent from my iPhone

> On Oct 8, 2018, at 8:23 PM, Dan Kortschak  
> wrote:
> 
> That is uncalled for.
> 
> Dan
> 
>> On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote:
>> I don’t think denigrating the most obvious advancement in computer
>> software in the last 20 years helps move things forward.
>> 
>> But to each his own, just please don’t work on anything with critical
>> safety issues please. Thanks for your understanding.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[Dan Kortschak]

That is uncalled for.

Dan

On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote:
> I don’t think denigrating the most obvious advancement in computer
> software in the last 20 years helps move things forward.
> 
> But to each his own, just please don’t work on anything with critical
> safety issues please. Thanks for your understanding.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[robert engels]

I don’t think denigrating the most obvious advancement in computer software in 
the last 20 years helps move things forward.

But to each his own, just please don’t work on anything with critical safety 
issues please. Thanks for your understanding.

> On Oct 8, 2018, at 4:03 PM, Dan Kortschak  
> wrote:
> 
> This is relevant here again.
> 
>> The European Commission has just announced an agreement whereby
>> English will be the official language of the European Union rather
>> than German, which was the other possibility. 
>> 
>> As part of the negotiations, the British Government conceded that
>> English spelling had some room for improvement and has accepted a 5-
>> year phase-in plan that would become known as "Euro-English". 
>> 
>> In the first year, "s" will replace the soft "c". Sertainly, this
>> will make the sivil servants jump with joy. The hard "c" will be
>> dropped in favour of "k". This should klear up konfusion, and
>> keyboards kan have one less letter.
>> 
>> There will be growing publik enthusiasm in the sekond year when the
>> troublesome "ph" will be replaced with "f". This will make words like
>> fotograf 20% shorter. 
>> 
>> In the 3rd year, publik akseptanse of the new spelling kan be
>> expekted to reach the stage where more komplikated changes are
>> possible. 
>> 
>> Governments will enkourage the removal of double letters which have
>> always ben a deterent to akurate speling. 
>> 
>> Also, al wil agre that the horibl mes of the silent "e" in the
>> languag is disgrasful and it should go away. 
>> 
>> By the 4th yer peopl wil be reseptiv to steps such as replasing "th"
>> with "z" and "w" with "v". 
>> 
>> During ze fifz yer, ze unesesary "o" kan be dropd from vords
>> kontaining "ou" and after ziz fifz yer, ve vil hav a reil sensi bl
>> riten styl. 
>> 
>> Zer vil be no mor trubl or difikultis and evrivun vil find it ezi TU
>> understand ech oza. Ze drem of a united urop vil finali kum tru. 
>> 
>> Und efter ze fifz yer, ve vil al be speking German like zey vunted in
>> ze forst plas. 
> 
> Replace "German" with "Java".
> 
> On Mon, 2018-10-08 at 08:04 -0500, Robert Engels wrote:
>> Yes, lobby to have Go2 include exceptions and then you don’t need to
>> worry about any of this... :)
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[Wojciech S. Czarnecki]

On Mon, 8 Oct 2018 08:04:46 -0500
Robert Engels  wrote:

> Yes, lobby to have Go2 include exceptions and then you don’t need to worry 
> about any of this... :)

You only will worry about thousands of things that your predecessors thrown at 
you just because "the schedule was tight".

Is it right time to lobby java ppl about removing 'do' and 'while' and some 
other twenty three keywords
to let Gophers feel better at java?

I solemnly promise a post advocating for try/catch construct in Go the day 
after you will succeed with convincing java's population to a vocabulary size 
of Go's.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[Dan Kortschak]

This is relevant here again.

> The European Commission has just announced an agreement whereby
> English will be the official language of the European Union rather
> than German, which was the other possibility. 
> 
> As part of the negotiations, the British Government conceded that
> English spelling had some room for improvement and has accepted a 5-
> year phase-in plan that would become known as "Euro-English". 
> 
> In the first year, "s" will replace the soft "c". Sertainly, this
> will make the sivil servants jump with joy. The hard "c" will be
> dropped in favour of "k". This should klear up konfusion, and
> keyboards kan have one less letter.
> 
> There will be growing publik enthusiasm in the sekond year when the
> troublesome "ph" will be replaced with "f". This will make words like
> fotograf 20% shorter. 
> 
> In the 3rd year, publik akseptanse of the new spelling kan be
> expekted to reach the stage where more komplikated changes are
> possible. 
> 
> Governments will enkourage the removal of double letters which have
> always ben a deterent to akurate speling. 
> 
> Also, al wil agre that the horibl mes of the silent "e" in the
> languag is disgrasful and it should go away. 
> 
> By the 4th yer peopl wil be reseptiv to steps such as replasing "th"
> with "z" and "w" with "v". 
> 
> During ze fifz yer, ze unesesary "o" kan be dropd from vords
> kontaining "ou" and after ziz fifz yer, ve vil hav a reil sensi bl
> riten styl. 
> 
> Zer vil be no mor trubl or difikultis and evrivun vil find it ezi TU
> understand ech oza. Ze drem of a united urop vil finali kum tru. 
> 
> Und efter ze fifz yer, ve vil al be speking German like zey vunted in
> ze forst plas. 

Replace "German" with "Java".

On Mon, 2018-10-08 at 08:04 -0500, Robert Engels wrote:
> Yes, lobby to have Go2 include exceptions and then you don’t need to
> worry about any of this... :)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[Liam]

The Go designers considered and discarded exceptions for common errors, 
then added panic/recover for truly exceptional circumstance. There are 
known problems with try/catch:
https://en.wikipedia.org/wiki/Exception_handling#Criticism

I've posted a comprehensive list of "possible requirements" for Go2 error 
handling. If it's missing any concepts that try/catch provides, could you 
raise them?
https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a

That page is linked from the feedback wiki I posted previously.

On Monday, October 8, 2018 at 10:37:43 AM UTC-7, Robert Engels wrote:
>
> I don’t think any of hat is true. Java has exceptions, it is highly 
> concurrent and it is very efficient.
>
> I just think that by the time yo get all of the “features” into Go error 
> handling that it needs for both reliability, debugging, etc., you are going 
> to end up with “exceptions” just with a different name and syntax - so I 
> say - why not just implement them to begin with. Passing errors up stream 
> (which is often the only reasonable thing to do in a complex system) is 
> error prone without stack traces (for logging), and types (for handling).
>
> The only difference between Go and Java here would be that Go’s are 
> interface based, where as in Java it uses a type hierarchy based off 
> Throwable.
>
> You can write poor Go error code now, there would be nothing stopping 
> someone from writing poor error code using exceptions, except at least with 
> exceptions it is obvious (by the catch and throw clauses) which errors the 
> code is handling and how… (if at all in bad code). With the current Go 
> error handling and the ability to use ‘_’ coupled with no API that controls 
> what errors can be seen/emitted (other than reading the specific API method 
> documentation, and even here you have to get lucky, including with the 
> stdlib methods) -  complex error situations in Go are much harder to handle.
>
> Simple situations are easy in Go right now, but the ‘error mechanism’ is 
> more flow control than error handling in many cases.
>
>
> On Oct 8, 2018, at 12:07 PM, Chris Hopkins  > wrote:
>
> {initial long rabley post deleted}
>
> If I understand the exception proposals, they are quite un-go-like. That 
> is go as a strongly typed, "no undeclared variables", etc language sits on 
> the side of more effort upfront to produce fewer bugs later trade-off. Try 
> ... catch however is more of the rough and ready "don't worry about the 
> details until I absolutely have to" philosophy.
> That's not to say they would be wrong for go, I just got the impression 
> exceptions - like interrupts - did not play well with concurrency and large 
> projects in general (Except in a "stop the world, I've subbed my toe" kind 
> of way).
>
> I can see for many classes of problems they could work very well and 
> certainly be convenient, but are they not kind of a "Forget about any 
> issues I might have, someone else will fix it" philosophy?
>
> {Hardware Engineer hat on}
> I can't help but think that Exceptions in the hardware sense are a costly 
> thing, in terms of latency, context switch and the higher level handler 
> trying to clean up the state afterwards. In a multi-processor system this 
> gets MUCH worse. They are errors in the strictest sense that should be rare.
> Perhaps this viewpoint is shading my outlook, of the different concept of 
> exceptions here.
> {Hat off}
>
> But I think that's what this is, not a question of utility, but of 
> philosophy, what type of language do people want go to be? Which scales to 
> large systems better? What is easier to understand when someone else has 
> written it? 
> I guess my fear of a catch type mechanism is coming along to find an 
> exception firing in someone else's code and all I see is "Out of Cheese 
> error", where that's an error that's used at every place in the code 
> anything goes wrong (I joke, but how many times have I seen code that just 
> goes log.Fatal("Error")). I could then come along and re-write every one of 
> those places to use different errors, but I would hope most people would 
> say that that behaviour was bad practice, to be fixed. I believe exceptions 
> would encourage, not discourage that behaviour.
>
> Sorry, my short post ended up quite long too!
>
> Regards
>
> Chris
> On Monday, 8 October 2018 16:46:28 UTC+1, Robert Engels wrote:
>>
>> I read the proposal and the only knock against including a stack trace by 
>> default is one google problem cited that was clearly bad error handling to 
>> begin with. 
>>
>> Why is there always some need to reinvent the wheel. Leave Go error 
>> handling as in and add a throws and catch that new code can use, with the 
>> current const based error instances - just add an interface Exception that 
>> all throw X need to implement in order to use, and catch on interfaces, not 
>> structs. 
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 

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

[Liam]

Note that the check/handle proposal has largely prompted counter-proposals 
and critique...
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

So I'd guess that the final product will look rather different :-)

On Monday, October 8, 2018 at 7:54:54 AM UTC-7, Chris Hopkins wrote:
>
> Thanks. Yes, that's exactly what I want, could I have Go2 now please? ;-)
>
> Okay I'll keep doing it the way I'm doing it with a mind to swapping to 
> that when available.
>
> I had avoided reading the Go2 proposal stuff simply because I regard 
> language design as a question for people with Marvin-like intellects. 
> That's way less scary than the generics proposals that worry me so much.
>
> Thanks again
>
> On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>>
>> On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins  
>> wrote: 
>> > Hi, 
>> > Could I please check what current error handling best practice is? 
>> ...
>> > Any suggestions gratefully received. 
>>
>> Have you seen the error handling thoughts at 
>> https://go.googlesource.com/proposal/+/master/design/go2draft.md ? 
>> The thoughts about "errors as values" seems relevant here. 
>>
>> Ian 
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.