Invitation to comment on proposed standard library multierror support #64
Comments
sywhang
pushed a commit
that referenced
this issue
Feb 10, 2023
Go 1.20 includes native support for wrapping multiple errors.
Errors which wrap multiple other errors must implement,
Unwrap() []error
If an error implements this method, `errors.Is` and `errors.As`
will descend into the list and continue matching.
Versions of Go prior to 1.20, however, still need the old
`Is` and `As` method implementations on the error object
to get a similar behavior.
This change adds the `Unwrap() []error` method
gated by a build constraint requiring Go 1.20 or higher.
It similarly moves the existing `Is` and `As` methods
to a file that is ignored on Go 1.20 or higher.
Once Go 1.21 is released and 1.19 is no longer supported,
the pre-go1.20 file may be deleted and the build constraints removed.
For details, see also the section,
"How should existing multierror types adopt the new interface?"
of the [multiple errors proposal][1].
[1]: golang/go#53435
Refs #64
|
Closing this issue as we've commented in the proposal, and multierr support is now shipped as part of Go 1.20 as well as the latest release of multierr. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi!
I have an in-review proposal to add support for wrapping multiple errors to the standard library. The latest version of the proposal is:
golang/go#53435 (comment)
This proposal is intended to allow interoperation between multierror implementations, as well as to simplify these implementations. It isn't intended to supplant existing implementations, except in the simplest of cases. The quick summary of the proposal is that
errors.Isanderrors.Aswould support descending into multiple errors when a type implements anUnwrap() []errormethod returning a list of wrapped errors; for details see the above link.I'm opening an issue in this repo to invite your comments on this proposal, either in the proposal issue or here. Would you find this feature useful? If adopted, would you add an
Unwrap() errorto your error types? Do you see any problems with this proposal, or are there changes that would make it more useful to you?Thanks!
The text was updated successfully, but these errors were encountered: