Re: [go-nuts] Go 2018 Survey "Error handling 5%"

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

-----Original Message-----
From: Chris Broadfoot
Sent: Jul 8, 2019 9:04 AM
To: Robert Engels
Cc: Chris Passas , golang-nuts
Subject: Re: [go-nuts] Go 2018 Survey "Error handling 5%"

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

On Mon, Jul 8, 2019, 9:54 AM Robert Engels <reng...@ix.netcom.com> wrote:

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

-- 

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/1215816141.2411.1562594037454%40wamui-charming.atl.sa.earthlink.net.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2090906623.3004.1562595459550%40wamui-charming.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.