On Fri, Dec 31, 2021 at 5:12 AM Brian Candler wrote:
> On Friday, 31 December 2021 at 08:10:49 UTC Henry wrote:
>
>> The purpose of error wrapping is to give contextual information about the
>> error. It is supposed to help you understand and locate the error. For
>> instance, *"invalid filename"
On Friday, 31 December 2021 at 08:10:49 UTC Henry wrote:
> The purpose of error wrapping is to give contextual information about the
> error. It is supposed to help you understand and locate the error. For
> instance, *"invalid filename"* is not particularly useful when compared
> to *"fail to
The purpose of error wrapping is to give contextual information about the
error. It is supposed to help you understand and locate the error. For
instance, *"invalid filename"* is not particularly useful when compared to
*"fail
to load customer data: invalid filename"*. Error wrapping is a stack
In your code, the cache layer always returns a non-nil error, even when the
value was found in the cache *and* the value was error-free. I don't think
that's realistic. You're changing "error" from an indication of a problem,
into auxiliary metadata about the value being returned (e.g. "this v
In practice, wrapping errors is handy for interfaces that have predefined
generic error types that will end up being logged. In code, you'd check the
error against that constant error with errors.Is(err, gateway.InvalidUser)
and handle it the same way, but when you log that error the extra messa
ISTM the alternative is return a semantically-meaningful error at the
current level of execution.
e.g. if you're trying to open a config file and it fails, you return
"Unable to open config file"; or better, include the text version of the
underlying error: e.g. "Unable to open config file: 'fo
Yes, of course I'm quite familiar with Go 1.13's error capabilities.
github.com/pkg/errors is still useful when one wants to attach stack traces
to errors.
But this leaves my question open: What are alternatives to wrapping
errors? (Other than passing around errors with no semantic meaning, a
Have you seen https://go.dev/blog/go1.13-errors?
If one wants to use error unwrapping, these days generally it is suggested
to use the functionality from the standard package "errors" (or fmt.Errorf)
rather than some third-party package. That way everyone does it the same
way, making third-part
