> Wrapping your errors produces great messages but defeats type switches for structured error handling. This pattern makes it easy to not actually have the erro

> Wrapping your errors produces great messages but defeats type switches for structured error handling. This pattern makes it easy to not actually have the error handling logic that that appears to be there. Not true. I've been successfully using error wrapping with type switches for years. That's what unwrapping is for. Go 1.13 has functions errors.Is(error) bool and errors.As(error, interface{}) bool and also errors.Unwrap(error) error. Package github.com/pkg/errors, which I use, only has function errors.Cause(error) error, but writing your own inspection helpers is trivial. > You need to be very careful about adding context, because you need your error monitoring system (Sentry, etc) to understand what are instances of the same failure mode vs. different failure modes. (…) Not sure about Sentry, but Airbrake has no issues with that.