Can Go’s New ‘?’ Operator Simplify Error Handling?

Background

Error handling is a crucial part of programming, and Go's verbose error handling has sparked much debate. The community discusses ways to reduce boilerplate while maintaining clarity and maintainability.

Proposal Details

Ian Lance Taylor proposed a new Go proposal #71203 to introduce a ? operator for error handling, simplifying Go code. The proposal suggests the following syntax transformation:

// now
result, err := someFunction()
if err != nil {
    return nil, err
}
// proposal ?
result := someFunction()?

Both versions behave the same: if someFunction() returns an error, it is returned.

The core idea is to reduce template code while keeping Go’s explicit and simple philosophy. The ? operator acts as syntactic sugar for functions returning (T, error), automatically checking the last return value for a non‑zero error.

Syntax Rules

?

can only appear at the end of an assignment or expression statement, and the expression must return a value.

For expression statements, ? “absorbs” the last value (usually err).

For assignment statements, ? “absorbs” the right‑hand side’s last value, causing the right side to have one more value than the left side.

The absorbed value is called a qvalue and must implement the error interface. ? may be followed by a block; if the qvalue is non‑nil, the function returns immediately, assigning the qvalue to the last return value.

If a block follows ?, the block executes when the qvalue is non‑nil, implicitly declaring an err variable with the same type as the qvalue.

Advantages

The main benefit is a reduction in repetitive error‑handling code. As quoted in the proposal, it reduces boilerplate from 9 tokens to 5, from 24 non‑whitespace characters to 12, and from 3 lines to 2.

reduces the error handling boilerplate from 9 tokens to 5, 24 non-whitespace characters to 12, and 3 boilerplate lines to 2.

Unlike previous proposals such as try, the ? operator does not introduce hidden control flow; its presence clearly indicates error handling logic.

Disadvantages

The biggest drawback is the need to update all Go documentation and code, and newcomers must learn this new concept, which differs from other languages. It also puts pressure on the Go Core Team, as the change affects many parts of the language.

Implicit err Variable

When a block follows ?, an implicit err variable is declared, which can cause variable shadowing. The proposal includes an example where assigning err = nil inside a loop must affect the outer err, but using ? would introduce a new err that shadows the outer one, potentially leading to compiler errors.

In this example, assigning err = nil must change the err variable outside the for loop; using ? would introduce a new err that shadows the outer variable.

Increased Cognitive Load

func F1() error {
    err := G1()
    log.Print(err)
    G2() ?
    {
        log.Print(err)
    }
    return nil
}

func F2() error {
    err := G1()
    log.Print(err)
    G2() ? {
        log.Print(err)
    }
    return nil
}

Both functions are legal, but the subtle difference in newline placement leads to different behavior, increasing the mental burden on developers.

Reasoning Against Change

Although Go’s error handling is often criticized, it remains functional. The proposal’s author repeatedly notes, “Perhaps no change is better than this change.” This reflects the Go Core Team’s hesitation to modify error handling without strong consensus.

泛型: 别Q我

Conclusion

The ? operator proposal offers a new approach to Go’s error handling, promising concise syntax and reduced boilerplate while keeping the main flow clear. Despite ongoing debates and potential drawbacks, it shows that the Go Core Team is still listening to community feedback.