Why Go Will NEVER Fix Error Handling

Go’s long-running effort to reduce the boilerplate of error handling is effectively stalled: after multiple Go-team proposals and hundreds of community alternatives, the project is choosing to stop pursuing new error-handling syntax “for the foreseeable future.” The core issue is familiar to Go programmers—repeated patterns like `if err != nil { return ... }` can turn real work into a thin layer surrounded by error-checking noise, especially in code that makes many API calls.

The Go team’s history shows how hard this problem has been to solve without breaking Go’s design priorities. The first major attempt dates to 2018, when Russ Cox described a “check and handle” approach based on earlier draft work by Marcel von Leoen Lohisen Laisen. That design included a broad comparison of alternatives, but it was judged too complicated. In 2019, a simplified “try” proposal followed, turning “check” into a `try` built-in function and omitting “handle.” While the mechanism was tested with a rewriting tool and prototyped in the compiler, it changed control flow by returning from the enclosing function—sometimes from deeply nested expressions—making the behavior harder to see and harder to reason about.

A later round of proposals continued to iterate, including a more recent direction attributed to Jimmy FRA that revisits the original check-and-handle concept with modifications intended to address earlier shortcomings. Yet even these refinements failed to win broad support. The proposal process itself becomes a bottleneck: when general consensus can’t be found in tracker discussions, proposals get declined, and without consensus the decision path ultimately falls to Go architects. The result is that none of the major syntax proposals reached the level of agreement needed to move forward.

One of the most concrete alternatives discussed is the “question mark” operator, borrowed from Rust’s ergonomics. Informal studies where programmers were shown Go code using this operator found that most participants correctly inferred its meaning. Ian Lance Taylor also built a tool to convert ordinary Go code into the proposed syntax and prototyped it in the compiler. Still, the proposal attracted a flood of comments and preferences for minor tweaks, and broad support never materialized.

Beyond consensus, the Go team highlights practical costs. Language changes are expensive: they require updating code, documentation, and tooling, and the Go team is small with many competing priorities. There are also arguments for leaving things alone—Go already has a workable error-handling model, and Go’s culture favors avoiding multiple ways to do the same thing. Even so, the team acknowledges the user pain: error handling remains a top complaint in developer surveys, and the lack of syntax support is most noticeable for programmers coming from languages with built-in error propagation.

In the end, the decision is pragmatic rather than optimistic. The team will stop pursuing syntax changes for error handling and close proposals focused primarily on error-handling syntax. The hope is that future work—possibly around improving how errors are constructed and augmented, or around better tooling and visibility—will clarify whether the real bottleneck is syntactic verbosity or the broader challenge of making errors useful and readable.