Go 1.13: xerrors
crawshaw.io
Go 1.13: xerrors
1–10 of 150 posts
Re: Go 1.13: xerrors
#2Speaking of errors, here's how i approach writing a good error message.
Fill in the blank "Well basically what happened is ___________"
For example i've found this has helped me to go from "Invalid phone number" to "The phone number needs to be 10 digits"
Re: Go 1.13: xerrors
#3Speaking of errors, here's how i approach writing a good error message. Fill in the blank "Well basically what happened is ___________" For example i've found this has helped me to go from "Invalid phone number" to "The phone number needs to be 10 digits"
Descriptive errors that match the business logic are ideal in many cases. Clearly, one shouldn't don't divulge "secret" validators.
More on the topic, I'm really happy to see this coming in so far ahead of 2.0. I want to get ready for 2.0 because of the gains I hope to see in idiomatic go in 2.0.
Re: Go 1.13: xerrors
#4This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney's errors package (which I love) into the standard library: https://github.com/pkg/errors
Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit.
I don't like the `fmt.Errorf("more description: %w", err)` though for several reasons.
Firstly it is a lot more opaque than Dave Cheney's original mechanism errors.Wrap(err, "more description"). You've got to check the format string for a `%w` to see if it is wrapping an error or not.
Secondly why is this really important functionality in `fmt` and not in `error`?
And finally we've been encouraged to write `fmt.Errorf("more description: %v", err)` (note `%v` not `%w`), so I think there will be a lot of unwrapped errors.
...
I'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.
IMHO I think this would be better staying as a non standard library package for the time being while more kinks are worked out.
Re: Go 1.13: xerrors
#5This seems way better than the other proposals. pkg/errors solved every complaint I had about errors years ago.
Re: Go 1.13: xerrors
#6This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney's errors package (which I love) into the standard library: https://github.com/pkg/errors Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit. I don't like the `fmt.Errorf("more description: %w", err)` though for several reasons. Firstly it is a lot more opaque than Dave Cheney's original mechanism…
+1 on all of this. I really prefer that https://github.com/pkg/errors is outside of the standard library so I don't need to use the fmt.Errorf abomination.
Re: Go 1.13: xerrors
#7Speaking of errors, here's how i approach writing a good error message. Fill in the blank "Well basically what happened is ___________" For example i've found this has helped me to go from "Invalid phone number" to "The phone number needs to be 10 digits"
Descriptive errors that match the business logic are ideal in many cases. Clearly, one shouldn't don't divulge "secret" validators. More on the topic, I'm really happy to see this coming in so far ahead of 2.0. I want to get ready for 2.0 because of the gains I hope to see in idiomatic go in 2.0.
This is the general strategy when developing "2.0": do as much as possible in a backwards compatible way, and if we never need to make a breaking change, never call a release 2.0. The new features process that was introduced recently may result in a 2.0 release, or it may result in 1.999, so you will continue to see new features in each release for a while regardless of what the release is called.
Re: Go 1.13: xerrors
#8This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney's errors package (which I love) into the standard library: https://github.com/pkg/errors Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit. I don't like the `fmt.Errorf("more description: %w", err)` though for several reasons. Firstly it is a lot more opaque than Dave Cheney's original mechanism…
>Secondly why is this really important functionality in `fmt` and not in `error`?
`fmt` already depends on `errors`, and Go does not allow cyclical dependencies, so `errors` would have to reimplement string formatting.
Re: Go 1.13: xerrors
#9As others have stated, this seems incredibly odd to me:
> If the last argument is an error and the format string ends with ": %w", ...
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.
Re: Go 1.13: xerrors
#10As others have stated, this seems incredibly odd to me: > If the last argument is an error and the format string ends with ": %w", ... 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 wra…
It is. It's a backwards-compatibility magic string hack. I would suggest new code uses the new, formal ways of obtaining the same result.
(I'm not defending it so much as explaining it. I'm not sure how I feel about it myself.)