Summary
A new try construct is proposed that is designed specifically to eliminate if -expressions commonly associated with error handling in Go. This is the only change in language. Authors support the use of defer and standard library functions to enrich or wrap errors. This small extension is suitable for most scenarios, practically without complicating the language.
The try construct is easy to explain, easy to implement, this functionality is orthogonal to other language constructs and is fully backward compatible. It is also extensible if we want it in the future.
The rest of this document is organized as follows: after a brief introduction, we give a definition of the built-in function and explain its use in practice. The discussion section reviews alternative suggestions and the current design. At the end, conclusions and an implementation plan with examples and a section of questions and answers will be given.
Introduction
At the last Gophercon conference in Denver, members of the Go team (Russ Cox, Marcel van Lohuizen) presented some new ideas on how to reduce the tediousness of manual error handling in Go ( draft design ). Since then we have received a huge amount of feedback.
As Russ Cox explained in his review of the problem , our goal is to make error handling more lightweight by reducing the amount of code devoted specifically to error checking. We also want to make writing error handling code more convenient, increasing the likelihood that developers will still devote time to correcting error handling. At the same time, we want to leave the error handling code clearly visible in the program code.
The ideas discussed in the draft draft are concentrated around the new unary check statement, which simplifies the explicit verification of the error value obtained from some expression (usually a function call), as well as the declaration of error handlers ( handle ) and a set of rules connecting these two new language constructs.
Most of the feedback we received focused on the details and complexity of the handle design, and the idea of a check operator turned out to be more attractive. In fact, several members of the community took the idea of a check operator and expanded it. Here are a few posts most similar to our offer:
- The first written proposal (known to us) to use the
check construct instead of the operator was proposed by PeterRK in his post Key parts of error handling - Not so long ago, Markus proposed two new keywords,
guard and must along with using defer to wrap errors in # 31442 - Also pjebs suggested a
must construct in # 32219
The current proposal, although different in detail, was based on these three and, in general, on the feedback received on the draft design proposed last year.
For completeness, we want to note that even more error handling suggestions can be found on this wiki page . It is also worth noting that Liam Breck came with an extensive set of requirements for the error handling mechanism.
Finally, after the publication of this proposal, we learned that Ryan Hileman implemented try five years ago using the og rewriter tool and successfully used it in real projects. See ( https://news.ycombinator.com/item?id=20101417 ).
Built-in try function
Sentence
We suggest adding a new function-like language element called try and called with a signature
func try(expr) (T1, T2, ... Tn)
where expr means an expression of an input parameter (usually a function call) that returns n + 1 values of types T1, T2, ... Tn and error for the last value. If expr is a single value (n = 0), this value must be of type error and try does not return a result. Calling try with an expression that does not return the last value of type error results in a compilation error.
The try construct can only be used in a function that returns at least one value, and whose last return value is of type error . Calling try in other contexts leads to a compilation error.
Call try with function f() as in the example
x1, x2, … xn = try(f())
leads to the following code:
t1, … tn, te := f()
In other words, if the last error type returned by expr is nil , then try simply returns the first n values, removing the final nil .
If the last value returned by expr is not nil , then:
- The
error return value of the enclosing function (in the pseudocode above named err , although this can be any identifier or unnamed return value) receives the error value returned from expr - there is an exit from the enveloping function
- if the enclosing function has additional return parameters, these parameters store the values that were contained in them before the
try call. - if the enclosing function has additional unnamed return parameters, the corresponding zero values are returned for them (which is identical to saving their original zero values with which they are initialized).
If try used in multiple assignments, as in the example above, and a non-zero error (hereinafter not-nil - approx. Per.) Is detected, the assignment (by user variables) is not executed, and none of the variables on the left side of the assignment does not change. That is, try behaves like a function call: its results are available only if try returns control to the caller (as opposed to the case with a return from the enclosing function). As a result, if the variables on the left side of the assignment are return parameters, using try will result in behavior that is different from the typical code that is encountered now. For example, if a,b, err are named return parameters of an enclosing function, here is this code:
a, b, err = f() if err != nil { return }
will always assign values to the variables a, b and err , regardless of whether the call to f() returned an error or not. Contrary challenge
a, b = try(f())
in case of an error, leave a and b unchanged. Despite the fact that this is a subtle nuance, we believe that such cases are quite rare. If unconditional assignment behavior is required, you must continue to use if expressions.
Using
The definition of try explicitly tells you how to use it: a lot of if expressions that check for an error return can be replaced with try . For example:
f, err := os.Open(filename) if err != nil { return …, err
can be simplified to
f := try(os.Open(filename))
If the calling function does not return an error, try cannot be used (see the Discussion section). In this case, the error should in any case be processed locally (since there is no error return), and in this case, if remains the appropriate mechanism for checking for errors.
Generally speaking, our goal is not to replace all possible error checks with a try . Code that requires different semantics can and should continue to use if expressions and explicit variables with error values.
Testing and try
In one of our earlier attempts to write a specification (see the design iteration section below), try was designed to panic when an error occurs when used inside a function without a return error. This allowed using try in unit tests based on the testing package of the standard library.
As one of the options, it is possible to use test functions with signatures in the testing package
func TestXxx(*testing.T) error func BenchmarkXxx(*testing.B) error
in order to allow the use of try in tests. A test function that returns a nonzero error will implicitly call t.Fatal(err) or b.Fatal(err) . This is a small library change that avoids the need for different behaviors (return or panic) for try , depending on the context.
One of the drawbacks of this approach is that t.Fatal and b.Fatal will not be able to return the line number on which the test fell. Another disadvantage is that we have to somehow change the subtests too. The solution to this problem is an open question; we do not propose specific changes to the testing package in this document.
See also # 21111 , which suggests allowing example functions to return an error.
Error processing
The original draft design was largely about language support for wrapping or augmenting errors. The draft proposed a new keyword handle and a new way to declare error handlers . This new language construct attracted problems like flies due to non-trivial semantics, especially when considering its effect on the flow of execution. In particular, the handle functionality miserably crossed with the defer function, which made the new language feature non-orthogonal to everything else.
This proposal reduces the original draft design to its essence. If enrichment or error wrapping is required, there are two approaches: attach to if err != nil { return err} , or "declare" an error handler inside the defer expression:
defer func() { if err != nil {
In this example, err is the name of the return parameter of type error enclosing function.
In practice, we imagine such helper functions as
func HandleErrorf(err *error, format string, args ...interface{}) { if *err != nil { *err = fmt.Errorf(format + ": %v", append(args, *err)...) } }
or something similar. The fmt package can become a natural place for such helpers (it already provides fmt.Errorf ). Using helpers, the definition of an error handler will in many cases be reduced to a single line. For example, to enrich the error from the copy function, you can write
defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)
if fmt.HandleErrorf implicitly adds error information. Such a construction is fairly easy to read and has the advantage that it can be implemented without adding new elements of the language syntax.
The main drawback of this approach is that the returned error parameter must be named, which potentially leads to a less accurate API (see the FAQ on this topic). We believe that we will get used to it when the appropriate style of writing code is established.
Efficiency defer
An important consideration when using defer as an error handler is efficiency. The defer expression is considered slow . We do not want to choose between efficient code and good error handling. Regardless of this proposal, the Go runtime and compiler teams discussed alternative implementation methods and we believe that we can make typical ways of using defer to handle errors comparable in efficiency to the existing “manual” code. We hope to add a faster implementation of defer in Go 1.14 (see also ticket CL 171158 , which is the first step in this direction).
Special cases go try(f), defer try(f)
The try construct looks like a function, and because of this, it is expected that it can be used anywhere where a function call is acceptable. However, if the try call is used in the go statement, things get complicated:
go try(f())
Here f() is executed when the go expression is executed in the current goroutine, the results of calling f are passed as arguments to try , which starts in the new goroutine. If f returns a nonzero error, try is expected to return from the enclosing function; however, there is no function (and there is no return parameter of type error ), because the code is executed in a separate goroutine. Because of this, we propose disabling try in a go expression.
Situation with
defer try(f())
looks similar, but here the semantics of defer mean that the execution of try will be delayed until it returns from the enclosing function. As before, f() evaluated when defer , and its results are passed to the deferred try .
try checks the error f() returned only at the very last moment before returning from the enclosing function. Without changing try behavior, such an error can overwrite another error value that the enclosing function is trying to return. This is confusing at best, and at worst provokes errors. Because of this, we propose that you prohibit calling try in the defer statement defer well. We can always reconsider this decision if there is a reasonable application of such semantics.
Finally, like the rest of the built-in constructs, try can only be used as a call; it cannot be used as a value function or in a variable assignment expression as in f := try (just as f := print and f := new are forbidden).
Discussion
Design Iterations
The following is a brief discussion of earlier designs that led to the current minimal proposal. We hope that this will shed light on the selected design solutions.
Our first iteration of this sentence was inspired by two ideas from the article “Key Parts of Error Handling,” namely, using the built-in function instead of the operator and the usual Go function to handle errors instead of the new language construct. Unlike that publication, our error handler had a fixed signature func(error) error to simplify matters. An error handler would be called by the try function if there was an error before try would exit the enclosing function. Here is an example:
handler := func(err error) error { return fmt.Errorf("foo failed: %v", err)
While this approach allowed the definition of effective user-defined error handlers, it also raised many questions that obviously did not have the correct answers: What should happen if nil is passed to the handler? Is it worth try panic or regard this as a lack of a handler? What if the handler is called with a non-zero error and then returns a null result? Does this mean that the error is "canceled"? Or should an enclosing function return an empty error? There were also doubts that the optional transfer of an error handler would encourage developers to ignore errors instead of correcting them. It would also be easy to do the correct error handling everywhere, but skip one use of try . Etc.
In the next iteration, the ability to pass a custom error handler was removed in favor of using defer to wrap errors. This seemed like a better approach because it made error handlers much more noticeable in the source code. This step also eliminated all issues regarding the optional transfer of handler functions, but demanded that the returned parameters with the error type be named if access was required (we decided that this was normal). Moreover, in an attempt to make try useful not only within functions that return errors, it was necessary to make the behavior of try context-sensitive: if try used at the package level, or if it was called inside a function that does not return an error, try automatically panicked when an error was detected. (And as a side effect, because of this property, the language construct was called must instead of try in that sentence.) The context-sensitive behavior of try (or must ) seemed natural and also quite useful: it would eliminate many user-defined functions used in expressions initializing package variables. It also opened up the possibility of using try in unit tests with the testing package.
However, the context-sensitive behavior of try was fraught with errors: for example, the behavior of a function using try could quietly change (panic or not) when adding or removing a return error to the signature of the function. This seemed too dangerous a property. The obvious solution was to split the try functionality into two separate must and try functions, (very similar to how it was suggested in # 31442 ). However, this would require two built-in functions, while only try directly related to better error handling support.
Therefore, in the current iteration, instead of including the second built-in function, we decided to remove the dual semantics of try and, therefore, allow its use only in functions that return an error.
Features of the proposed design
This suggestion is quite short and may seem like a step back compared to last year's draft. We believe that the selected solutions are justified:
First things first, try has exactly the same semantics of the check statement proposed in the original with no handle . This confirms the fidelity of the original draft in one of the important aspects.
Choosing a built-in function instead of operators has several advantages. It does not require a new keyword like check , which would make the design incompatible with existing parsers. There is also no need to expand the syntax of expressions with a new operator. Adding a new built-in function is relatively trivial and completely orthogonal to other features of the language.
Using an inline function instead of an operator requires the use of parentheses. We should write try(f()) instead of try f() . This is the (small) price we have to pay for backward compatibility with existing parsers. However, this also makes the design compatible with future versions: if we decide along the way that passing in some form an error handling function or adding an additional parameter to try for this purpose is a good idea, adding an additional argument to the try call will be trivial.
As it turned out, the need to write brackets has its advantages. In more complex expressions with multiple try calls, parentheses improve readability by eliminating the need to deal with operator precedence, as in the following examples:
info := try(try(os.Open(file)).Stat())
try , : try , .. try (receiver) .Stat ( os.Open ).
try , : os.Open(file) .. try ( , try os , , try try ).
, .. .
conclusions
. , . defer , .
Go - , . , Go append . append , . , . , try .
, , Go : panic recover . error try .
, try , , — — , . Go:
, , . if -.
Implementation
:
- Go.
try . , . .go/types try . .gccgo . ( , ).- .
- , . , . .
Robert Griesemer go/types , () cmd/compile . , Go 1.14, 1 2019.
, Ian Lance Taylor gccgo , .
"Go 2, !" , .
1 , , , Go 1.14 .
Examples
CopyFile :
func CopyFile(src, dst string) (err error) { defer func() { if err != nil { err = fmt.Errorf("copy %s %s: %v", src, dst, err) } }() r := try(os.Open(src)) defer r.Close() w := try(os.Create(dst)) defer func() { w.Close() if err != nil { os.Remove(dst)
, " ", defer :
defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)
( defer -), defer , .
printSum
func printSum(a, b string) error { x := try(strconv.Atoi(a)) y := try(strconv.Atoi(b)) fmt.Println("result:", x + y) return nil }
:
func printSum(a, b string) error { fmt.Println( "result:", try(strconv.Atoi(a)) + try(strconv.Atoi(b)), ) return nil }
main :
func localMain() error { hex := try(ioutil.ReadAll(os.Stdin)) data := try(parseHexdump(string(hex))) try(os.Stdout.Write(data)) return nil } func main() { if err := localMain(); err != nil { log.Fatal(err) } }
- try , :
n, err := src.Read(buf) if err == io.EOF { break } try(err)
Questions and answers
, .
: ?
: check handle , . , handle defer , handle .
: try ?
: try Go . - , . , . , " ". try , .. .
: try try?
: , check , must do . try , . try check (, ), - . . must ; try — . , Rust Swift try ( ). .
: ? Rust?
: Go ; , Go ( ; - ). , ? , . , , , (package, interface, if, append, recover, ...), , (struct, var, func, int, len, image, ..). Rust ? try — Go, , ( ) . , ? . , , (, ..) . . , .
: ( error) , defer , go doc. ?
: go doc , - ( _ ) , . , func f() (_ A, _ B, err error) go doc func f() (A, B, error) . , , , . , , . , , , -, (deferred) . Jonathan Geddes try() .
: defer ?
: defer . , , defer "" . . CL 171758 , defer 30%.
: ?
: , . , ( , ), . defer , . defer - https://golang.org/issue/29934 ( Go 2), .
: , try, error. , ?
: error ( ) , , nil . try . ( , . - ).
: Go , try ?
: try , try . super return -, try Go . try . .
: try , . What should I do?
: try ; , . try ( ), . , if .
: , . try, defer . What should I do?
: , . .
: try ( catch )?
: try — ("") , , ( ) . try ; . . "" . , . , try — . , , throw try-catch Go. , (, ), ( ) , . "" try-catch , . , , . Go . panic , .