Error handling (github.com/github/errors vs stdlib)

[jtlisi]

Since Go 1.13, there has been error handling support in standard library to wrap errors and check for wrapped error types. This is primarily handled using the fmt.Errorf function with the %w verb. Currently we use the github.com/pkg/errors package which includes similar functionality to the standard library, with the addition of some additional utility functions.

In most cases I feel we should move our error wrapping approach to use the standard library since it solves the primary use case of wrapping errors and maintaining the errors type. However, we use the pkg/errors package across our code base both internal and vendored packages. I just wanted to create a thread to center discussions around this.

[pstibrany]

I prefer pkg/errors package for several reasons:

• It has nicer API:
  • Wrap, Wrapf handle nil gracefully which allows for nice shortcuts (eg. return errors.Wrap(f.Close(), "close failed") would only return wrapped error if f.Close() returned error)
  • New / Errorf are natural extensions of stdlib functions
  • Is / As for compatibility with stdlib functions.
• Wrapping produces standard-looking messages automatically (<extra text>: <wrapped error>)
• It has support for stacktraces – although we don't really use that feature
• We already use it extensively and it is also used by Prometheus and Thanos codebase
• Errors produces by pkg/errors are compatible with stdlib errors.As/Is/Unwrap functions.

Benefits of using only fmt.Errorf and errors.New from stdlib would be:

• one less external dependency (although not really reducing binary size, since it would still be linked from other places)
• more free-form formatting, which could be useful in certain cases
• no stacktrace capture = slightly faster generation of error

Negative of switching is the need to change it at lot of places in the codebase.

To me switching to stdlib-only errors package doesn't seem to be worth the effort.