Gopher Wrangling. Effective error handling in Go

When programming in Go, the amount of error handling is something that slaps you in the face. Most API’s you deal with will expose errors. It can become overwhelming, but with a few tips and a guiding principle we can make handling errors easy, keep our code clean and give you the confidence that nothing is breaking in production.

A cartoon of a crazy stressed programmer pulling their hair out in front of lots of screens showing a error exclamation marks

A cartoon of a crazy stressed programmer pulling their hair out in front of lots of screens showing a error exclamation marks

Guiding principle

The goal for our error handling strategy is that it should require minimal effort and provide an easy way to debug any errors that do occur.

1. Always handle errors

Always handle errors. Sometimes it’s tempting to skip one, you might not expect that error to ever happen. But that’s why it’s an exception! You need to handle it so that you can find out clearly if it ever does happen.

If you don’t handle the error, the expected value will be something else and just lead to another error that will be harder to debug, or worse it could lead to data corruption.

In most cases to handle the error all you need to do is return it to the caller of your method, where they can log it.

For example, when refreshing some data you might load it, then save it. If you skip the error handling it could overwrite potentially useful data with corrupt data.

👎 Bad error handling

func refresh() {
    bytes, _ := loadData()
    saveData(bytes)
}

👍 Good error handling

func refresh() error {
    bytes, err := loadData()
    if err != nil {
        return err
    }
    saveData(bytes)
}

2. Log errors in one layer

You always want to log your errors, ideally to something that will notify you about the error, so you can fix it. There is no point logging the error multiple times at every layer. Make it the top layer’s responsibility and don’t log in any services or lower level code.

Make sure your logging framework is including stack traces so you can trace the error to its cause.

For example in a web app you would log the error in the http handler when returning the Internal Server status code.

👍 Good error handling

func refresh() error {
    bytes, err := loadData()
    if err != nil {
        return err
    }
    saveData(bytes)
}

func (h *handlers) handleRefreshRequest(w http.ResponseWriter, r *http.Request) {
    err := refresh()
    if err != nil {
        log.Error("unexpected error processing request %w", err)
        w.WriteHeader(http.StatusInternalServerError)
        return
    }

    w.WriteHeader(http.StatusOK)
}

3. Returning async errors

When processing data concurrently using a go-func’s, it can be annoying to return the error. But if you don’t your app will be less maintainable. To handle async errors, return them via a channel to the calling thread.

👎 Bad error handling

func refreshManyConcurrently() {
    go func(){
        refresh(1)
    }()

    go func(){
        refresh(2)
    }()
}

👍 Good error handling

func refreshManyConcurrently() error {
    errors := make(chan error, 2)
    go func(){
        errors <- refresh(1)
    }()

    go func(){
        errors <- refresh(2)
    }()
    return multierror.Combine(<-errors, <- errors)
}

When calling functions that return a value and a possible error using a type like Result[T], to wrap the response to pass on the channel.

type Result[T any] struct {
    Value T
    Error error
}

4. Wrapping errors

Sometimes you want to add additional context to an error message. Eg to include the id of the request that caused the error. You can use fmt.error for this.

err := saveToDb(user)
if err != nil {
    return fmt.errorf("unexpected error saving user. userId=%v error=%w", user.Id, err)
}

Usually this isn’t necessary and its better to just return the error unwrapped.

5. Downgrade errors Warnings

There are types of errors that regularly occur during normal operation. The system might not be able to prevent them all the time, but they don’t need to investigate every time. It is better to treat them as warnings rather than errors. These might be for things like timeouts or intermittent connection errors.

👍 Good error handling

func (h *handlers) handleRefreshRequest(w http.ResponseWriter, r *http.Request) {
    err := refresh()
    if err != nil {
        if err == context.DeadlineExceeded {
            log.Warn("Timeout error processing request %w", err)
        } else {
            log.Error("unexpected error processing request %w", err)
        }

        w.WriteHeader(http.StatusInternalServerError)
        return
    }

    w.WriteHeader(http.StatusOK)
}

Source link