🔗 [ On | No ] syntactic support for error handling

One of the oldest and most persistent complaints about Go concerns the verbosity of error handling. We are all intimately (some may say painfully) familiar with this code pattern:

x, err := call()
if err != nil {
        // handle err
}

The test if err != nil can be so pervasive that it drowns out the rest of the code. This typically happens in programs that do a lot of API calls, and where handling errors is rudimentary and they are simply returned. Some programs end up with code that looks like this:

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return err
    }
    y, err := strconv.Atoi(b)
    if err != nil {
        return err
    }
    fmt.Println("result:", x + y)
    return nil
}

Of the ten lines of code in this function body, only four (the calls and the last two lines) appear to do real work. The remaining six lines come across as noise. The verbosity is real, and so it’s no wonder that complaints about error handling have topped our annual user surveys for years. (For a while, the lack of generics surpassed complaints about error handling, but now that Go supports generics, error handling is back on top.)

The Go team takes community feedback seriously, and so for many years now we have tried to come up with a solution for this problem, together with input from the Go community.