Consider enabling tomarrell/wrapcheck

[atc0005]

Overview

Description from the project README:

A simple Go linter to check that errors from external packages are wrapped during return to help identify the error source during debugging.

From the linked blog post:

Hence, it would be helpful to have a simple set of rules to follow for when errors should be wrapped. This is by no means an exhaustive set, however should cover the majority of common cases within most programs.

1. When you have additional context, which you think would be useful to give to the developer reading the log. This is important, as rules are not infallible.
2. Errors returned from another package. Wrapping these helps identify the entry point of the error into your program.
3. Errors returned by interface methods. Interfaces may be implemented by a separate package, therefore wrapping the errors here with context may be valuable.

...

Wrapcheck is a new linter for Go which I built in order to maintain consistency across a codebase with regards to point (1) and (2).

This is in contrast to the goerr113 linter which enforces these linting rules:

1. error values should not be compared directly but with errors.Is() method.
2. error should not be created dynamically from scratch but by the wrapping the static (package-level) error.

NOTE: This linter is also included in the golangci-lint project.

References

• https://github.com/tomarrell/wrapcheck
• https://blog.tomarrell.com/post/introducing_wrapcheck_linter_for_go
• https://github.com/Djarvur/go-err113
• https://golangci-lint.run/usage/linters/