Chapter 7 Error Handling on Go: Under the Hood

7.1 The Evolution of the Problem

Mon, 01 Jan 0001 00:00:00 +0000

7.1 The Evolution of the Problem

In 6.3 we already drew the dividing line: how to handle errors is one of the fundamental choices in language design. The exception camp (C++, Java, Python) uses try/catch to pull the error path out of the normal logic, keeping the main line clean, at the cost of making the error path implicit, capable of being thrown from any call site. The value camp (Go, Rust, and C’s return-code tradition) passes errors explicitly as ordinary return values: verbose, but every error path is spelled out in black and white with nowhere to hide. Go chose the value camp, reserving a lightweight panic/recover only for “true exceptions.” What this section is about is what happened after that choice landed: how the proposition of “errors as values” itself evolved, from a string you could only print into a tree that a program can interrogate layer by layer, asking “are you really that error?”

7.2 Inspecting Error Values

Mon, 01 Jan 0001 00:00:00 +0000

7.2 Inspecting Error Values

Once an error propagates up a call chain, the code that handles it and the code that produced it are often separated by many layers. This raises a plain but thorny question: given an error that has been passed up through layer after layer, how does the caller decide “is this actually some particular error”, and how does it retrieve the specific error value that originally carried the context? This section answers exactly that, along with the conventions Go has set down for it in the errors package.

7.3 Error Format and Context

Mon, 01 Jan 0001 00:00:00 +0000

7.3 Error Format and Context

A good error does not merely say “something went wrong.” It tells a person what was being done, on account of what, and what went wrong. The evolution of the problem (7.1) and value inspection (7.2) gave us the mechanisms for propagating and examining errors. This section discusses the engineering practice that sits on top of those mechanisms: how the text of an error should be written, how context accumulates layer by layer along the call chain, and how stack traces and structured logs can be added on demand when human-written words are not enough. Running through all of it is one overall tendency Go has regarding error information: human-written semantic context is preferable to machine-collected stack traces.

7.4 Error Semantics

Mon, 01 Jan 0001 00:00:00 +0000

7.4 Error Semantics

7.2 and 7.3 stood on the caller’s side of an error and worked out how, once you hold an error, to inspect it along the chain and how to layer context onto it. This section turns the viewpoint to the other side, standing with the library author and asking a question that comes before inspection: when a package wants to expose a failure to the outside world, what form should it give that error? Should it export a comparable value, export a type with fields, or export nothing at all?

7.5 The Future of Error Handling

Mon, 01 Jan 0001 00:00:00 +0000

7.5 The Future of Error Handling

In the preceding sections we saw the plainness of the error interface, %w wrapping, and the inspection of error chains. By this point the reader probably carries an unspoken question: those three lines of if err != nil boilerplate, spread year after year across every Go program, is there really no way to get rid of them? The question is not a lonely one. From the go2 draft of 2018 to a single conclusion in 2025, the Go team weighed it back and forth for seven years, proposing several syntaxes such as check/handle, try, and ?, and then withdrawing them one by one. This section places that path of failed syntax side by side with another, quietly successful path of library evolution, and lays out the judgment the Go team finally arrived at: for the foreseeable future, error handling will not receive any dedicated syntax.