Closed Devcon4 closed 2 years ago
@jakobottar That is fine, those run in a different context anyways so it doesn't even make sense for them to throw a panic. They should log the error then close quietly. As far as pkg/errors
it is unfortunate, neither the standard library replaces what it's goal is nor is the package still maintained. I would replace it with fmt.Errorf("My wrapper message: %w", err.Error())
or make a simple helper like this.
func Wrapf(err error, format string, args ...interface{}) error {
if err == nil {
return nil
}
return fmt.Errorf(fmt.Sprintf(format, args...)+": %w", err)
}
This is basically a simplified version of errors.wrapf, the source for .wrapf and fmt.Errorf is easy to read and do basically the same thing if you want to make your own. Cool thing with go is it's very easy to read the standard library code and is what everyone uses as an example of good go code.
I would also consider using a Structured Logging library like zerolog or zap. In cases where you want to log extra info when an error happens (timestamp, interfaces, etc) you wouldn't want that to be wrapped in an error. Instead you should have a simple error which is handled but log an error event with all of that info.
too old, closing in favor of new error-handling branch
@Devcon4 So we've got a problem: Handlers, like these, cannot return anything, even
nil
, which kinda breaks your error handling schema. In the meantime, I just log them and move on, as those handlers won't encounter panic-worthy errors.Also, the
errors
package you're using is out of date, I'll look into the newer method. It looks like it's almost identical but doesn't use that package.