Description
Current Status
The Fabric project intentionally adopted use of github.com/pkg/errors package for error handling and publicized the guidance at:
https://hyperledger-fabric.readthedocs.io/en/latest/error-handling.html
The rationale at the time was that github.com/pkg/errors injected stack trace context at the point of error in low level code, which could be easily logged at higher levels of the control flow with the %+v formatter verb, and layers of code inbetween could add message context using WithMessage(), or simply pass the existing stack trace context up with the familiar and simple error handling like this:
if err != nil {
return err
}
Since that time, Go added better error wrapping support in errors standard library as of Go 1.13 as described in the blog and wiki, and github.com/pkg/errors got archived as not needed anymore.
Goal
The project should transition away from the archived package github.com/pkg/errors.
I see two basic approaches:
Approach 1 - Switch to errors package in standard library
It makes logical sense to use the standard errors package now, however without the stack trace context available anymore, each layer that passes an error up should add its own context, either by extending the error message or using the new wrappering approach available in standard library errors package.
The downside is that transitioning to the standard library errors package will require a large work effort to update all the code, as we really don't want a mismatch of error handling assumptions and techniques across a single code flow. The best time to make an exhaustive change like this would be at a major release boundary, for example between v2.x and v3.x.
Approach 2 - Keep overall approach by copying github.com/pkg/errors into a fabric errors package
If we want to preserve the stack trace and limit the code changes, there isn't much risk of keeping the overall github.com/pkg/errors approach. Although the project is archived, the project was simple and didn't pull in other dependencies. The utility code could easily be copied into a fabric specific errors package to eliminate the external dependency on github.com/pkg/errors, while keeping the existing overall approach and the associated benefits of having stack trace available.
This approach would be simpler in the short term, but would come at the cost of maintaining the (small amount) of utility code, and educating developers to use it.
The purpose of this issue is to finalize an approach and then update the developer guidance and code accordingly.