Error-Handling

The Go proposal committee has declined the try proposal.

I am disappointed. I also think this is open source working exactly as it should.

The proposal was not dropped because one person with commit access disliked it. A concrete design was published, tools were written to try it on existing code, hundreds of examples and objections were discussed, and the people behind it kept answering questions long after I would have quietly disconnected my router and moved to the woods.

Most importantly, the Proposal Review Committee made its decision in response to that discussion. The closing note mentions problems the original design had missed, including debugging prints and code coverage. It also admits something more fundamental: many Go programmers do not agree that the verbosity of error forwarding is a problem worth changing the language to solve.

That is a good reason to stop. A language belongs to the people who have to read it, and a change to control flow needs more than a clever specification. The community worked through the tradeoffs together and the committee made the call. I may disagree with the result, but I trust the process far more after seeing it work.

Still, I think this will eventually look like a missed opportunity.

The argument against try was strongest when it was used inside nested expressions:

return write(encode(try(read(name))))

I do not want to debug that either. But bad nesting was not the only possible future. The ordinary form was much less alarming:

b := try(ioutil.ReadFile(name))
try(json.Unmarshal(b, &cfg))

One operation per line, errors still in the function signature, no exceptions, and an explicit if whenever local handling mattered. I think that style would have become normal very quickly. It looks unusual today mostly because it is new.

There is a difficult bias in evaluating syntax: familiar boilerplate does not feel like syntax anymore. We see if err != nil and read “return the error.” We see try and inspect every unusual corner because it is new. That scrutiny is necessary before changing a language, but it is not a neutral comparison.

Rust went through a remarkably similar argument around try! and later ?. People worried about hidden control flow and two ways to write the same thing. Once programmers had lived with it, many came to consider it one of the language’s better features. Go is not Rust and should not become Rust, but people do learn new control-flow notation. We already did it with defer and go.

There is another group absent from a discussion among current Go programmers: people who did not choose Go because they found its error handling tedious. It is almost impossible to measure them from inside the community. The people most comfortable with the status quo are, unsurprisingly, the people who stayed.

None of that means the committee should have ignored the reaction and forced try through. That would have damaged the language and the community more than a little error boilerplate ever could. Declining it was the right decision now, given the lack of agreement about both the problem and the solution.

But I suspect we solved the social problem by leaving the technical one untouched. Years from now we may add something remarkably similar under another name, after enough other languages have made the idea feel ordinary. Or we may simply keep writing the same four lines and insist they are valuable because we have become very fast at not seeing them.

Either way, try was worth trying. The proposal improved our understanding of the problem, and its rejection proved that the Go community can say no even after a great deal of work has been invested.

That is not failure. I just hope it is not the last word on improving error handling.

It has been six days since the try proposal was posted and the issue already has hundreds of comments.

Robert Griesemer has posted a useful summary of the discussion. After reading far too much of the thread, I think the arguments are clearer now. They are also better than “I hate typing if err != nil” versus “real programmers enjoy typing it,” which is where these discussions usually go to die.

The strongest case for try is ordinary sequential code:

func readConfig(name string) (*Config, error) {
	b := try(ioutil.ReadFile(name))
	var cfg Config
	try(json.Unmarshal(b, &cfg))
	return &cfg, nil
}

There is very little error handling in the expanded version. Both errors are simply returned. The extra if statements interrupt the description of what the function does without adding a decision.

This is not merely speculation. Some people have tried converting code from the standard library. One conclusion was that try made most of those examples easier to read. Another person looked at much the same evidence and reached almost exactly the opposite conclusion.

The proposal has other good properties. It does not introduce exceptions. Errors remain ordinary return values. Existing code keeps working. try handles the dull case while an if remains available whenever the error needs local attention. I find that separation appealing.

The invisible return

The best argument against it is simple: try looks like a function call but changes the control flow of its caller.

Consider this:

req.Header = Header(try(tp.ReadMIMEHeader()))

That assignment can return from the enclosing function. A struct literal containing try can return. A nested expression can contain several possible returns on the same source line. Today my eyes know that constructing a value does not quietly leave the function. With try, they would have to search inside every expression.

Some commenters therefore prefer a keyword or statement form:

try f := os.Open(name)

It is harder to miss, but it is also a larger language change and it gives up the proposal’s useful ability to fit where an expression fits. Restricting try may make it safer while removing much of what makes it attractive. Language design is fun like that.

There are practical problems too. If I add a debugging print to one particular failure today, there is an obvious block in which to put it. If several operations use try and one deferred handler wraps all of their errors, identifying the exact operation may require changing the code back to an if.

Coverage has a similar problem. The explicit error block is visible to coverage tools. A hidden return inside try creates a branch that source-level coverage needs to represent somehow. Debuggers and stack traces also need enough information to distinguish multiple try calls on one line. These are practical objections, not just a matter of taste.

The context problem

I am less convinced by the proposed use of defer for error context than I am by try itself.

A deferred handler can add function-level context once:

defer fmt.HandleErrorf(&err, "reading configuration %s", name)

That is lovely when every failure in the function deserves the same context. It is less useful when opening the file, parsing it, and validating it each need different information. The handler also runs on every return and encourages named error results. None of this is fatal, but it means the proposal is strongest exactly where error forwarding is least interesting.

So I still like try, with qualifications large enough to require their own parking space. I would avoid nesting it and use one operation per line. I would keep if err != nil wherever an error needs local context, cleanup, logging, or translation. In that style the hidden control flow is bounded and the useful code becomes much easier to see.

But Go cannot add a feature on the assumption that everybody will use my preferred style. If nested try is legal, nested try will exist. If a return can hide in a composite literal, people will write code that does exactly that.

I thought the original proposal was likely to fail because it felt unlike Go. The discussion has produced better reasons than feelings. I still think we may be rejecting an idea that would become ordinary and useful with time, but it is no longer difficult to understand why so many people are wary of it.

Yesterday Robert Griesemer posted a proposal for a new try built-in in Go. I have read the design document twice now and I think I like it.

I am not entirely comfortable saying that.

Two years ago I wrote that explicit error handling was exactly one of the things I loved about Go. I still do. The interesting question here is whether returning an error unchanged really counts as handling it.

The proposal turns this:

f, err := os.Open(filename)
if err != nil {
	return nil, err
}

into this:

f := try(os.Open(filename))

If os.Open returns an error, try places it in the enclosing function’s error result and returns from that function. Otherwise it gives us the other result. Errors remain values, functions still say that they return errors, and there are no exceptions jumping across some unknowable number of stack frames.

That is the part I like. A surprising amount of Go code is not really handling an error at all. It is checking the error and immediately passing it to the caller. I love explicit error handling, but writing four lines does not make that decision four times more explicit.

And yet try feels wrong.

It looks like a function but it can return from the function that called it. That is not something ordinary Go functions can do. The control flow is hidden inside an expression, and Go has spent the last ten years making control flow painfully, wonderfully obvious. There is no return on the line. It just returns.

The proposed way to add context also takes some getting used to. Instead of wrapping each error where it happens, a function can use a deferred handler to decorate the returned error. Using the helper sketched in the design, it would look something like this:

func readConfig(name string) (cfg Config, err error) {
	defer fmt.HandleErrorf(&err, "read configuration %s", name)

	data := try(ioutil.ReadFile(name))
	try(json.Unmarshal(data, &cfg))
	return cfg, nil
}

I am not sure I love the named result or the indirection in the handler. But I do like being able to see the actual operation without each line being separated from the next by the same little error-return ceremony.

My guess is that this proposal will not pass. It is a small addition in terms of specification and implementation, but a radical change in how Go code reads. Those are often the hardest changes: technically tiny and culturally enormous.

I also suspect that, if it does not pass, we may look back several years from now and wonder why it seemed so frightening. New syntax always has the disadvantage of looking unfamiliar in every example. The existing syntax has had a decade to become invisible.

Maybe I am wrong and try will turn real programs into a collection of secret exits. But the idea behind it is sound: keep explicit errors, while admitting that forwarding an error is not the interesting part of error handling.

That seems worth trying.