project-stacker / stacker

Build OCI images natively from a declarative format
https://stackerbuild.io
Apache License 2.0
197 stars 34 forks source link

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

Open rchincha opened 1 year ago

rchincha commented 1 year ago

Discussed in https://github.com/project-stacker/stacker/discussions/376

Originally posted by **hallyn** December 19, 2022 The errors package has been "archived" (https://github.com/pkg/errors/issues/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 commented 11 months ago

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.