Skip to content
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

Topic: should we continue to force errors.Errorf()? #380

Open
rchincha opened this issue Dec 28, 2022 Discussed in #376 · 1 comment
Open

Topic: should we continue to force errors.Errorf()? #380

rchincha opened this issue Dec 28, 2022 Discussed in #376 · 1 comment

Comments

@rchincha
Copy link
Contributor

Discussed in #376

Originally posted by hallyn December 19, 2022
The errors package has been "archived" (pkg/errors#245). errors.Wrapf() is supposed to be replaced by fmt.Errorf("%w"). However, (1) %w output is not liked by some, and more importantly (2) fmt.Errorf does not yet support a way to add a stack trace, which was the original reason for requiring errors.Errorf() in the stacker package.

What should be the official guidance right now? Should we continue recommending/requiring the errors package, or switch?

@mitar
Copy link

mitar commented Oct 9, 2023

Shameless plug: you can switch to drop-in replacement gitlab.com/tozd/go/errors. It fixes many issues, is maintained, and supports modern Go's error patterns (sentinel errors, %w formatting, joined errors, etc.). It also provides some nice utility functions and structured details so that it is easy to extract dynamic data out of errors (instead of trying to get them out of formatted strings). Has improved error formatting and JSON marshaling of errors. It is interoperable with other errors packages and does not require a dependency on itself to extract data (e.g., stack trace) from errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants