Go 1.13: xerrors

This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney&#x27;s errors package (which I love) into the standard library: <a href="https:&#x2F;&#x2F;github.com&#x2F;pkg&#x2F;errors" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pkg&#x2F;errors</a><p>Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit.<p>I don&#x27;t like the `fmt.Errorf(&quot;more description: %w&quot;, err)` though for several reasons.<p>Firstly it is a lot more opaque than Dave Cheney&#x27;s original mechanism errors.Wrap(err, &quot;more description&quot;). You&#x27;ve got to check the format string for a `%w` to see if it is wrapping an error or not.<p>Secondly why is this really important functionality in `fmt` and not in `error`?<p>And finally we&#x27;ve been encouraged to write `fmt.Errorf(&quot;more description: %v&quot;, err)` (note `%v` not `%w`), so I think there will be a lot of unwrapped errors.<p>...<p>I&#x27;m not sure enough has been thought about the backwards incompatibility. With rclone I try to maintain compatibility with the current go release and a few previous ones so that rclone can remain running with distro go versions and gccgo both of which are a bit behind. For something as common as error handling this will cause lots of libraries to suddenly be no longer usable with anything less than go1.13.<p>IMHO I think this would be better staying as a non standard library package for the time being while more kinks are worked out.

It seems like golang designers are totally isolated from what&#x27;s been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It&#x27;s sad because I use this language extensively but its weirdly mediocre design is totally unfathomable. It&#x27;s like they are very stubborn to do anything but the right thing.

From what I have seen, the Go 2 Error Values plan[1] has not received enough exposure to generate the level of feedback necessary to support a go&#x2F;no-go decision re a major change in 1.13 -- one we cannot opt-out of, at that.<p>I suspect that the overwhelming majority of Go developers has no idea this is in the works. It was covered once on the blog last August in the Draft Design summary, when there wasn&#x27;t any code behind it. It was not mentioned in Go 2 Here We Come[2], nor at the start of the below golang-dev thread. It was mentioned on golang-dev when I posted a link to the issue tracker in late January, but my posts would see a fraction of the attention vs those by Rob, Robert, Russ, Ian, et al.<p>There are outstanding issues with the current draft, specifically its performance[3] and API[4].<p>If it lands in 1.13, please give it Experimental status, with a build or env flag to disable changes to existing APIs, and perhaps a way to re-enable them on a per-function or per-package basis.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;29934" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;29934</a><p>[2] <a href="https:&#x2F;&#x2F;blog.golang.org&#x2F;go2-here-we-come" rel="nofollow">https:&#x2F;&#x2F;blog.golang.org&#x2F;go2-here-we-come</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;29934#issuecomment-486503822" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;29934#issuecomment-48650...</a><p>[4] <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;29934#issuecomment-483509242" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;29934#issuecomment-48350...</a><p>.<p>[Originally posted on golang-dev, in response to &quot;Last call for feedback on Go 1.13...&quot;]<p><a href="https:&#x2F;&#x2F;groups.google.com&#x2F;d&#x2F;topic&#x2F;golang-dev&#x2F;jPY0RYXSvCU&#x2F;discussion" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;d&#x2F;topic&#x2F;golang-dev&#x2F;jPY0RYXSvCU&#x2F;dis...</a>

As others have stated, this seems incredibly odd to me:<p>&gt; If the last argument is an error and the format string ends with &quot;: %w&quot;, ...<p>This seems like a magic-string kinda hack to me. I like the idea of wrapping errors so that you keep the stack and full context, especially since you may need additional structured data from all errors (e.g. DB error, access error, ...) to produce user facing messages, so IMHO the wrapping should be more explicit than just %w.

Speaking of errors, here&#x27;s how i approach writing a good error message.<p>Fill in the blank &quot;Well basically what happened is ___________&quot;<p>For example i&#x27;ve found this has helped me to go from &quot;Invalid phone number&quot; to &quot;The phone number needs to be 10 digits&quot;

Go error handling. Slowly re-inventing Java&#x27;s exceptions one use case at a time.

This seems way better than the other proposals. pkg&#x2F;errors solved every complaint I had about errors years ago.

Not sure why people are bashing Go because of it&#x27;s choices.<p>Looking forward to shit storm once they introduce generics in near future. I am sure people will still complain that this is not how parametric polymorphism should be implemented.

I think this is a positive development and should be cheered by Go programmers. Slowly but surely they progress on the road to implementing Exceptions. (<i>ducks and runs</i> like a scaredy cat to avoid the wrath of Go Fans)

What I&#x27;m really looking for is being able to debug any production Go binary by inspecting the stack trace behind an error. Could be gated by an environment variable.