jakobottar / ava-go

Discord bot written in Go
MIT License
1 stars 1 forks source link

Format errors; Restructure main #4

Closed Devcon4 closed 2 years ago

jakobottar commented 2 years ago

@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.

Devcon4 commented 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.

jakobottar commented 2 years ago

too old, closing in favor of new error-handling branch