Go 2018 Survey "Error handling 5%"

[Chris Passas]

We are all aware error handling was tied for 4th most common challenging when working with Go in the 2018 survey.

There is not description of what about error handling. I'm sure I missed the conversation but how did we get to the point of deciding it was the if err!=nil that was the "challenging part"?

Personally the only thing I wish was different was we could have error times/categories in addion. Basically just a way to allow us to not need the following.

if strings.Contains(err.Err(),"timeout")

Most of the time all you care is there was an error and don't parse the message to decide what to do next. There are cases where you might decide how to handle it based on the message.

There are messages like "Connection failed to -> 192.168.1.1", this is useful but also makes the error something you can't check for without substring parsing.

What if we could do something like

if err.Type()=="Bad Connection"

but then you could still return or log the 'err' as normal and get that extra info.

[Jan Mercl]

On Mon, Jul 8, 2019 at 3:33 PM Chris Passas <cpa...@gmail.com> wrote:
>
> We are all aware error handling was tied for 4th most common challenging when working with Go in the 2018 survey.

It's 5th, not 4th. (src: https://blog.golang.org/survey2018-results)

[Chris Passas]

Number 4,5,6 on the list all are listed at 5% so that's why I said "tied" for 4th. Not sure this is an important point of discussion.

[Robert Engels]

I think you are on to something. As I've said, the boilerplate is ugly, but manageable. It is the process of using and reporting errors that is the problem.

If the error interface were expanded, to included methods like

int Type()

int SubType()

[]Stack StackTrace()

error Cause()

Log(w Writer,string format,...) 

with stdlib defining constants for errors, and user developed constants > N, the chances of constant collision is minimal.

Alternatively, define like this

string Type()

string SubType()

with the Type being package.SomeErrorName

and sub-type being package.SomeErrorName.SubErrorName

to allow easier capture and retry.

To go even further, add a 

bool Permanent()

to signify if the same call is made with the same parameters, it is also fail - unless some action is taken (network reconfig, etc.) This is a more difficult implementation, but could be just a 'hint'.

It's is some amount of work to define the constants, and change existing code, but it is just busy work. The Go error handling is worse than C in that at least in C, the api doc clearly spells out which error codes can be returned, and why. With the Go error interface, and the 'minimal api doc', what is returned when is anybody's guess.

-----Original Message-----
From: Chris Passas
Sent: Jul 8, 2019 8:32 AM
To: golang-nuts
Subject: [go-nuts] Go 2018 Survey "Error handling 5%"

We are all aware error handling was tied for 4th most common challenging when working with Go in the 2018 survey.

There is not description of what about error handling. I'm sure I missed the conversation but how did we get to the point of deciding it was the if err!=nil that was the "challenging part"?

Personally the only thing I wish was different was we could have error times/categories in addion. Basically just a way to allow us to not need the following.

if strings.Contains(err.Err(),"timeout")

Most of the time all you care is there was an error and don't parse the message to decide what to do next. There are cases where you might decide how to handle it based on the message.

There are messages like "Connection failed to -> 192.168.1.1", this is useful but also makes the error something you can't check for without substring parsing.

What if we could do something like

if err.Type()=="Bad Connection"

but then you could still return or log the 'err' as normal and get that extra info.

--
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/fa12d854-c317-4477-98b1-32ca883d2093%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Passas]

Thank you, I think you did a better job describing than I did. I think this could be done backward compatible because if the "Type()" "SubType()" etc... are not filled out they could just default to returning the Err() value.

It would be good to get the whole standard library to support this but for all third party code it can default to err.Err() for unpopulated type fields.

In other languages with "exceptions" its common to test for what "type" of exception not the string error message. I would guess that the majority of people listing "Error handling" has a challenge are along these lines rather than if err!=nil is a "challenge".

I think most Go programmers GET the idea that its not suppose to be a pretty language/syntax so potentially having a bunch of if err!=nil isn't a big deal. 

I often have this conversation with others. I would never say my work output is limited by how fast I can type code. Most of the time I'm just thinking and intermittently typing. Making me able to type less characters really isn't an issue worth addressing if the trade off is less understandable code.

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Chris Broadfoot]

See the errors proposal here:

https://golang.org/design/29934-error-values

Implementation in tip (available in 1.13 beta)

https://tip.golang.org/pkg/errors/

Implementation in x/xerrors (backwards compatible):

https://godoc.org/golang.org/x/xerrors

xerrors - GoDoc

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1215816141.2411.1562594037454%40wamui-charming.atl.sa.earthlink.net.

[Jan Mercl]

On Mon, Jul 8, 2019 at 3:48 PM Chris Passas <cpa...@gmail.com> wrote:
>
> Number 4,5,6 on the list all are listed at 5% so that's why I said "tied" for 4th.

Sorry, you're right.

[Robert Engels]

I think the xerrors proposal will solve a lot of people's problems. You still repetitive boilerplate, but at least decent debugging is possible.