proposal: Go 2: introduce try/guard keyword for error handling

[andig]

Go has suffered from seen a number of Go2 error handling proposals. I'm joining the chorus as I had the feeling that a comparatively less disruptive permutation of the discussion has not come up before. I'd be totally happy if this got closed right away, in that case sorry for wasting everybody's time.

Goals of this proposal:

1. decrease verbosity, i.e. less typing and clearer structure of the non-error case
2. full control over error handling, including annotating the error
3. avoid hidden or non-local control flow magic

Before going to the details, I have considered:

• proposal: Go 2: block scoped error handling #33161 (block-scoped error handling) which attracted a comment for verbostity in proposal: Go 2: block scoped error handling #33161 (comment) but also was compared with Swift's guard in proposal: Go 2: block scoped error handling #33161 (comment).
• Proposal: A built-in Go error check function, "try" #32437 (A built-in Go error check function, "try") which I personally feel introduces too much non-local error handling (using defer) and allows for hard to read nested calls of try()
• proposal: Go 2: simplify error handling with try err == nil {} except {} #33387 (simplify error handling with try err == nil) which attracted this notable comment proposal: Go 2: simplify error handling with try err == nil {} except {} #33387 (comment) (unique per-statement error handling)
• Proposal: Go2: Drying up Error Handling in Go #36284 which partially failed due to Proposal: Go2: Drying up Error Handling in Go #36284 (comment) (fails to address the most common case of uniquely annotating errors in-situ.)

Proposal

This is an adapted version of #33161 (comment), I couldn't find an original proposal to this case (/cc @carlmjohnson).

In short, I'm proposing to introduce a try keyword similar to Swift's guard that will be implemented as an error-checking and error-handling specific alternative to the existing if statement:

• try must me followed by an assignment expression where the last assignment parameter must be an error and can be omitted
• if the error parameter is omitted, a non-nil error (and other zero value or initialised variables) will be returned alongside with it. This does not require the error to be named in the API
• if the try statement has a handler block, the block will be executed/ the error can be handled similar to if err != nil and returned or not. This typically requires the err parameter to be named.
• unlike the if statement, a special scoping rule allows the assigned target variables (right term?) to escape the block (I understand this is similar to swift). This includes the error variable if it is named.

As such, this proposal is similar to #33161 (comment), taking the comments regarding control flow from #33161 (comment) into account.

Syntactically, the two following statements are equivalent:

try foo := bar()

try foo := bar() {
    return
}

It would look like

TryStmt = "try" AssignmentExpression [ Block ]

Examples

CopyFile

func CopyFile(src, dst string) error {
	try r := os.Open(src) // returns the error
	defer r.Close() // returns the error

	try w := os.Create(dst) // returns the error
	defer w.Close() // returns the error

	try io.Copy(w, r) // returns the error
	try w.Close() // returns the error
}

Update: Obviously this example needs an additional rule for error precedence during defer (tbd). Updated the defer Syntax. Using try inside deferred functions follows the same rules as everywhere else.

Hex

func main() {
	try hex, err := ioutil.ReadAll(os.Stdin) {
		log.Fatal(err)
	}

	try data := parseHexdump(string(hex)) {
		log.Fatal(err)
	}

	os.Stdout.Write(data)
}

Some thoughts

As @carlmjohnson said:

• I think if something like this is done, it should be called guard because that's a name used by another language.
• Probably it's not enough better than `if to be adopted.

[earthboundkid]

What are the semantics of defer try w.Close()? Does it only assign an error if the existing error is non-nil? That would solve a real problem IMO.

I think the thing that really killed the last try proposal was that it made code coverage wrongly consider a try line “covered” even if it didn’t take the error path. Is there a way to handle that for try without a block in this proposal? Maybe auto-rewrite as a return block in coverage?

[andig]

I think the thing that really killed the last try proposal was that it made code coverage wrongly consider a try line “covered” even if it didn’t take the error path.

@carlmjohnson could you link that proposal? Not sure which one you're referring to- I feel it's the one I couldn't find in my research?

[earthboundkid]

#32437

[andig]

What are the semantics of defer try w.Close()? Does it only assign an error if the existing error is non-nil? That would solve a real problem IMO.

@carlmjohnson removed that syntax as it obscured the flow of the error variable (and if ... defer is not legal either).

[simskij]

I'm still not sure I get what adding some kind of try semantic to the language would solve that is not already addressed by if err != nil? One of the key strengths of go, in my opinion, is that it's strict and simple, without the unnecessary cognitive overhead introduced by offering multiple ways to solve the same problem.

[bitfield]

it's not enough better than if to be adopted

I think this is exactly right. It doesn't go far enough to satisfy the people who find writing if err != nil irritating, and it's entirely unnecessary for everybody else.

[andig]

It doesn't go far enough to satisfy the people who find writing if err != nil irritating

I beg do disagree. I don't think you could reduce this much more unless sacrificing other aspects:

• 1 line instead of three for the simple case
• no need for err!=nil in the complex case
• clear flow from code outline

... and it's entirely unnecessary for everybody else.

The number of error handling proposals, including those of go team members, shows that there is a wider need.

[simskij]

The number of error handling proposals, including those of go team members, shows that there is a wider need.

At the same time, the fact that the proposals keep getting shot down indicates that the need so far has not outweighed the added complexity.