This is a discussion about a new syntax that may be used to handle errors. This is issue #71203 converted into a discussion.
I've written a tool that converts ordinary Go code into code that uses the syntax from the proposal at #71203. That tool is available at https://go.dev/cl/643996. In order to build and use it you must first apply the changes in the patch series ending at https://go.dev/cl/642502.
Using that tool, I've converted much of the standard library to the new syntax. This can be seen at https://go.dev/cl/644076.
I encourage people interested in this proposal to take a look at these changes. Please consider whether the new code is more or less clear to the reader. Please consider whether the code logic stands out more clearly when there is less syntax devoted to error handling.
Most importantly, please avoid preconceptions when looking at this code. I'm not insisting that this change is better. But if you look at the changed code having already decided that this proposal is a bad idea, we won't learn anything. Really try to see whether the new code is better or worse.
If you choose to comment on how this proposal affects the standard library, please show specific examples to demonstrate your point. Don't argue in the abstract; look at real uses of real code.
The rest of this comment is largely a copy of #71203, partly updated, with some parts omitted.
Background
See #71203 for more background.
The goal of this proposal is to introduce a new syntax that reduces the amount of code required to check errors in the normal case, without obscuring flow of control.
New syntax
This section is an informal description of the proposal, with examples. A more precise description appears below.
I propose permitting statements of the form
r, err := SomeFunction() if err != nil { return fmt.Errorf("something failed: %v", err) }
to be written as
r := SomeFunction() ? { return fmt.Errorf("something failed: %v", err) }
The ? absorbs the error result of the function. It introduces a new block, which is executed if the error result is not nil. Within the new block, the identifier err refers to the absorbed error result.
Similarly, statements of the form
if err := SomeFunction2(); err != nil { return fmt.Errorf("something else failed: %v", err) }
may be written as
SomeFunction2() ? { return fmt.Errorf("something else failed: %v", err) }
Further, I propose that the block following the ? is optional. If the block is omitted, it acts as though there were a block that simply returns the error from the function. For example, code like
if err := SomeFunction2(); err != nil { return err }
may in many cases be written as
Formal proposal
This section presents the formal proposal.
An assignment or expression statement may be followed by a question mark (?). The question mark is a new syntactic element, the first permitted use of ? in Go outside of string and character constants. The ? causes conditional execution similar to an if statement. A ? at the end of a line causes a semicolon to be automatically inserted after it.
A ? uses a value as described below, referred to here as the qvalue.
For a ? after an assignment statement, the qvalue is the last of the values produced by the right hand side of the assignment. The number of variables on the left hand side of the assignment must be one less than the number of values produced by the right hand side (the right hand side values may come from a function call as usual). It is not valid to use a ? if there is only one value on the right hand side of the assignment.
For a ? after an expression statement the qvalue is the last of the values of the expression. It is not valid to use a ? after an expression statement that has no values.
The qvalue must be of interface type and must implement the predeclared type error; that is, it must have the method Error() string. In most cases it will simply be of type error.
A ? is optionally followed by a block. The block may be omitted if the statement using ? appears in the body of a function, and the enclosing function has at least one result, and the qvalue is assignable to the last result (this means that the type of the last result must implement the predeclared type error, and will often simply be error).
Execution of the ? depends on the qvalue. If the qvalue is nil, execution proceeds as normal, skipping over the block if there is one.
If the ? is not followed by a block, and the qvalue is not nil, then the function returns immediately. The qvalue is assigned to the final result. If the other results (if any) are named, they retain their current values. If they are not named, they are set to the zero value of their type. The results are then returned. Deferred functions are executed as usual.
If the ? is followed by a block, and the qvalue is not nil, then the block is executed. Within the block a new variable err is implicitly declared, possibly shadowing other variables named err. The value and type of this err variable will be those of the qvalue.
That completes the proposal.
Discussion
This new syntax is partly inspired by Rust's question mark operator, though Rust permits ? to appear in the middle of an expression and does not support the optional block. Also, I am suggesting that gofmt will enforce a space before the ?, which doesn't seem to be how Rust is normally written.
Absorbing the error returned by a function, and optionally returning automatically if the error is not nil, is similar to the earlier try proposal. However, it differs in that
?is an explicit syntactic element, not a call to a predeclared function, and?may only appear at the end of the statement, not in the middle of an expression.
Declaring the err variable
As discussed above, when a block follows the ? it implicitly declares a new err variable. There are no other cases in Go where we implicitly declare a new variable in a scope. Despite that fact, I believe this is the right compromise to maintain readability while reducing boilerplate.
A common suggestion among early readers of this proposal is to declare the variable explicitly, for example by writing
r := SomeFunction() ? err { return fmt.Errorf("something failed: %v", err) }
In practice, though, the variable would essentially always be simply err. This would just become additional boilerplate. Since the main goal of this proposal is to reduce boilerplate, I believe that we should try our best to do just that, and introduce err in the scope rather than requiring people to declare it explicitly.
If the implicit declaration of err seems too problematic, another approach would be to introduce a new predeclared name. The name err would not be appropriate here, as that would be too often shadowed in existing code. However, a name like errval or erv would work. Within a ? optional block, this name would evaluate to the qvalue. Outside of a ? optional block, referring to the name would be a compilation error. This would have some similarities to the predeclared name iota, which is only valid within a const declaration.
A third approach would be for errval or erv to be a predeclared function that returns the qvalue.
Supporting other types
As discussed above the qvalue must be an interface type that implements error. It would be possible to support other interface types. However, the ? operator, and especially the implicitly declared err variable, is specifically for error handling. Supporting other types confuses that focus. Using ? with non-error types would also be confusing for the reader. Keeping a focus on just handling errors seems best.
It would also be possible to support non-interface types that implement error, such as the standard library type *os.SyscallError. However, returning a value of that type from a function that returns error would mean that the function always returns a non-nil error value, as discussed in the FAQ. Using different rules for ? would make an already-confusing case even more confusing.
Effects on standard library
The latest version of the conversion tool found 723,292 statements in the standard library. It was able to convert 14,304 of them to use ?. In all, 1.98% of all statements were changed. 2,825 statements, or 0.39% of the total, were changed to use a ? with no optional block.
In other words, adopting this change across the ecosystem would touch an enormous number of lines of existing Go code. Of course, changing existing code could happen over time, or be skipped entirely, as current code would continue to work just fine.
Pros and cons
Pros
Advantage 1: Rewriting
r, err := SomeFunction() if err != nil { return fmt.Errorf("something failed: %v", err) }
to
r := SomeFunction() ? { return fmt.Errorf("something failed: %v", err) }
reduces the error handling boilerplate from 9 tokens to 5, 24 non-whitespace characters to 12, and 3 boilerplate lines to 2.
Rewriting
r, err := SomeFunction() if err != nil { return err }
to
reduces boilerplate from 9 tokens to 1, 24 non-whitespace characters to 1, and 3 boilerplate lines to 0.
Advantage 2: This change turns the main code flow into a straight line, with no intrusive if err != nil statements and no obscuring if v, err = F() { … } statements. All error handling either disappears or is indented into a block.
Advantage 3: That said, when a block is used the } remains on a line by itself, unindented, as a signal that something is happening. (I'm also listing this as a disadvantage, below.)
Advantage 4: Unlike the try proposal and some other error handling proposals, there is no hidden control flow. The control flow is called out by an explicit ? operator that can't be in the middle of an expression, though admittedly the operator is small and perhaps easy to miss at the end of the line. I hope the blank before it will make it more visible.
Advantage 5: To some extent this reduces a couple of common error handling patterns to just one, as there is no need to decide between
var ( v string err error ) if v, err = F(); err != nil { ... }
and
v, err := F() if err != nil { ... }
Instead people can consistently write
Cons
Disadvantage 1: This is unlike existing languages, which may make it harder for novices to understand. As noted above it is similar to the Rust ? operator, but still different. However, it may not be too bad: Todd Kulesza did a user study and discovered that people unfamiliar with the syntax were able to see that the code had to do with error handling.
Disadvantage 2: The shadowing of any existing err variable may be confusing. Here is an example from the standard library where the ? operator can not be easily used:
fmt/scan.go:
for n = 1; !utf8.FullRune(r.buf[:n]); n++ { r.buf[n], err = r.readByte() if err != nil { if err == io.EOF { err = nil // must change outer err break } return } } // code that later returns err
In this example the assignment err = nil has to change the err variable that exists outside of the for loop. Using the ? operator would introduce a new err variable shadowing the outer one. (In this example using the ? operator would cause a compiler error, because the assignment err = nil would set a variable that is never used.)
Disadvantage 3: When using a block, the } remains on a line itself, taking up space as pure boilerplate. (I'm also listing this as an advantage, above.)
Disadvantage 4: No other block in Go is optional. The semicolon insertion rule, and the fact that a block is permitted where a statement is permitted, means that inserting or removing a newline can convert one valid Go program into another. As far as I know, that is not true today.
For example, these two functions would both be valid and have different meanings, although the only difference is whitespace.
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 }
Disadvantage 5: For an expression statement that just calls a function that returns an error, it's easy to accidentally forget the ? and write F() rather than F() ?. Of course it's already easy to forget to check the error result, but once people become accustomed to this proposal it may be easy to overlook the missing ? when reading code.
Disadvantage 6: This proposal has no support for chaining function calls, as in F().G().H(), where F and G also have an error result.
Disadvantage 7: This proposal makes it easier to simply return an error than to annotate the error, by using a plain ? with no block. This may encourage programmers to skip error annotations even when they are desirable.
Disadvantage 8: We really only get one chance to change error handling syntax in Go. We aren't going to make a second change that touches 1.5% of the lines of existing Go code. Is this proposal the best that we can do?
Disadvantage 9: We don't actually have to make any changes to error handling. Although it is a common complaint about Go, it's clear that Go is usable today. Perhaps no change is better than this change. Perhaps no change is better than any change.
Transition
If we adopt this proposal, we should provide tools that can be used to automatically rewrite existing Go code into the new syntax. Not everyone will want to run such a tool, but many people will. Using such a tool will encourage Go code to continue to look the same in different projects, rather than taking different approaches. This tool can't be gofmt, as correct handling requires type checking which gofmt does not do. It could be an updated version of go fix. See also modernizers.
We will have to update the go/ast package to support the use of ?, and we will have to update all packages that use go/ast to support the new syntax. That is a lot of packages.
We will also have to update the introductory documentation and the tour. And, of course, existing Go books will be out of date and will need updating by their authors. The change to the language and compiler is the easiest part of the work.