-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
proposal: errors: add errors.Mark to support error marks #50819
Comments
It appears that this can be implemented in a third party package. Why should this be in the standard library? See https://go.dev/doc/faq#x_in_std. |
What is an error mark? I'm not familiar with the term. Thanks. |
how is this different from the previously declined multi error proposals, eg #47811 |
In my case, we need errors.Mark if we just want to mark current to handle specially later, like same error with different code
|
|
#50800 is a PR / CL / implementation which is on hold while this issue / proposal goes through the process |
Thanks for the replies. I still don't see a reason why this should be in the standard library. |
Whether or not this proposal is accepted, I'm curious how others have approached this problem in a graceful and go-native way. |
Sorry, missed that #50800 was a PR and not an issue. As Ian said, it seems like it would make sense to implement this outside the standard library and gauge how useful it is. |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely decline. |
No change in consensus, so declined. |
Issue #50800 proposes a way to support error marks without any side effect.
Background
Currently,
fmt.Errorf("error occur: %w", err)
supports traversing a linked chain of errors by%w
, but parallel%w
is not allowed, such asfmt.Errorf("error occur: %w, %w", err)
.Concerns
We need one general way to support marks, that is:
errors.Is
returns true if and only if err or any marks match the target errerrors.Is
and '%v' infmt
.Proposed changes to the
errors
packageI propose that the following API be added to the
errors
package:Ideally, a developer could write the following error handling:
Workarounds
The following is a proposed implementation of errors.Mark in Issue #50800 :
You can also find an implementation with test cases in the Go Playground: https://go.dev/play/p/J6-Zn4QBC81
See also
proposal: errors: simplified error inspection
The text was updated successfully, but these errors were encountered: