-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.Is
anderrors.As
would support descending into multiple errors when a type implements anUnwrap() []error
method 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() error
to 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: