Gopher Wrangling. Efficient error dealing with in Go

When programming in Go, the quantity of error dealing with is one thing that slaps you within the face. Most API’s you cope with will expose errors. It might turn out to be overwhelming, however with a number of suggestions and a guideline we will make dealing with errors straightforward, hold our code clear and provide the confidence that nothing is breaking in manufacturing.

A cartoon of a loopy burdened programmer pulling their hair out in entrance of plenty of screens displaying a error exclamation marks

Tenet

The objective for our error dealing with technique is that it ought to require minimal effort and supply a straightforward strategy to debug any errors that do happen.

1. At all times deal with errors

At all times deal with errors. Typically it’s tempting to skip one, you may not anticipate that error to ever occur. However that’s why it’s an exception! You must deal with it to be able to discover out clearly if it ever does occur.

For those who don’t deal with the error, the anticipated worth shall be one thing else and simply result in one other error that shall be tougher to debug, or worse it might result in information corruption.

Usually to deal with the error all you could do is return it to the caller of your technique, the place they’ll log it.

For instance, when refreshing some information you may load it, then reserve it. For those who skip the error dealing with it might overwrite doubtlessly helpful information with corrupt information.

???? Unhealthy error dealing with

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

???? Good error dealing with

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

2. Log errors in a single layer

You all the time wish to log your errors, ideally to one thing that may notify you concerning the error, so you’ll be able to repair it. There isn’t a level logging the error a number of instances at each layer. Make it the highest layer’s accountability and don’t log in any providers or decrease degree code.

Make sure that your logging framework is together with stack traces so you’ll be able to hint the error to its trigger.

For instance in an online app you’d log the error within the http handler when returning the Inner Server standing code.

???? Good error dealing with

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("surprising error processing request %w", err)
        w.WriteHeader(http.StatusInternalServerError)
        return
    }

    w.WriteHeader(http.StatusOK)
}

3. Returning async errors

When processing information concurrently utilizing a go-func’s, it may be annoying to return the error. However when you don’t your app shall be much less maintainable. To deal with async errors, return them through a channel to the calling thread.

???? Unhealthy error dealing with

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

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

???? Good error dealing with

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

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

When calling capabilities that return a worth and a doable error utilizing a kind like End result[T], to wrap the response to cross on the channel.

kind End result[T any] struct {
    Worth T
    Error error
}

4. Wrapping errors

Typically you wish to add further context to an error message. Eg to incorporate the id of the request that prompted the error. You need to use fmt.error for this.

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

Often this isn’t vital and its higher to only return the error unwrapped.

5. Downgrade errors Warnings

There are varieties of errors that repeatedly happen throughout regular operation. The system may not be capable to stop them on a regular basis, however they don’t want to analyze each time. It’s higher to deal with them as warnings quite than errors. These could be for issues like timeouts or intermittent connection errors.

???? Good error dealing with

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("surprising error processing request %w", err)
        }

        w.WriteHeader(http.StatusInternalServerError)
        return
    }

    w.WriteHeader(http.StatusOK)
}