You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes I miss the capabilities of the standard library to handle errors. Wrapping an error in context with fmt.Errorf("some context: %w",err) is a great feature. But there are situations where having multiple errors of the form
var errMyError1 = errors.New("my error 1")
var errMyError2 = errors.New("my error 2")
I need to pack them both into an error followed by the ability to detect this fact with
I think a function like NewJoinedErrors might be useful for someone and should probably be included in the errors package.
The only drawback I see is some inconvenience in managing the text context. The context can be added for the overridden errors separately or later for the resulting error.
As a user, it would be more convenient for me to use fmt.Errorf("some context %w: and more context: %w", errExt, errInt) notation instead of the proposed construct. In this case, the errExt, errInt ratio under the hood is specified by the order of variables, which may not be quite obvious (meaning which error will be retrieved first during Unwrap).
Another option is to add a specifier for external error: fmt.Errorf("some context %w: and more context: %W", errInt, errExt), so the user knows that errExt will be extracted first, though I cannot immediately imagine a situation where this really matters.
I believe that the above changes will not spoil backward compatibility and will give error handling a more generic look.
The text was updated successfully, but these errors were encountered:
ianlancetaylor
changed the title
proposal: errors:
proposal: errors: add NewJoinedErrors
Oct 6, 2021
This proposal is a duplicate of a previously discussed proposal, as noted above,
and there is no significant new information to justify reopening the discussion.
The issue has therefore been declined as a duplicate.
— rsc for the proposal review group
Description
Sometimes I miss the capabilities of the standard library to handle errors. Wrapping an error in context with
fmt.Errorf("some context: %w",err)
is a great feature. But there are situations where having multiple errors of the formI need to pack them both into an error followed by the ability to detect this fact with
Example Implementation
At the moment, I'm using my own type to solve such problems:
Using the following function
i can get what i want.
Example Using
You can try it here
Conclusion
I think a function like NewJoinedErrors might be useful for someone and should probably be included in the errors package.
The only drawback I see is some inconvenience in managing the text context. The context can be added for the overridden errors separately or later for the resulting error.
As a user, it would be more convenient for me to use
fmt.Errorf("some context %w: and more context: %w", errExt, errInt)
notation instead of the proposed construct. In this case, the errExt, errInt ratio under the hood is specified by the order of variables, which may not be quite obvious (meaning which error will be retrieved first during Unwrap).Another option is to add a specifier for external error:
fmt.Errorf("some context %w: and more context: %W", errInt, errExt)
, so the user knows that errExt will be extracted first, though I cannot immediately imagine a situation where this really matters.I believe that the above changes will not spoil backward compatibility and will give error handling a more generic look.
The text was updated successfully, but these errors were encountered: