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. On Monday, July 8, 2019 at 9:54:24 AM UTC-4, Robert Engels 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 golan...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/fa12d854-c317-4477-98b1-32ca883d2093%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/fa12d854-c317-4477-98b1-32ca883d2093%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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/91601f63-4d9b-4c1a-8b13-0ec201d26d4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
