Proposal: Go2: try: Change try() proposal to use a special character in the position where an error is returned

[integrii]

It looks like #32437 is the current most popular error handling proposal. This proposal wishes to introduce a try() statement that returns the default values of all return variables if a value other than nil is returned as the last value from a function. In normal function, the try() statement returns all values that are not the final error value.

How about instead of wrapping things in parentheses all over the place, we directly put a special key (like !! or anything else) into the place where the error is returned? That's shorter and all other behaviour is the same. Also, you don't have invisible returns here, or require the error to be the last thing returned.

This also discourages changing try statements together which keeps code more readable.

func Foo() (err error) {
        file, !! = os.Open("file1.txt")
        defer file.Close()
	parsed, !! = parseFile(file)
	fmt.Printf("%s", parsed)
	return nil
}

[networkimprov]

This has been suggested many times. See #32500 and
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes

It even appears a few times within the comments on try().

[ianlancetaylor]

This seems quite cryptic for people unfamiliar with Go. That's not a fatal problem, but it is a cost.

[alanfo]

It was also suggested at #32601 which used ? as the special character though this was soon closed by the OP, presumably due to lack of support.

Although I personally prefer #32437 for the reasons stated there, I do think this is one of the better alternative proposals. Points in its favor include:

1. It does save significant boiler-plate and the syntax is quite pleasant.

2. It's backwards compatible since, apart from a named identifier (usually err), the only other symbol currently allowed in this position is _.

3. It's easy to change from this syntax to what we do currently do now which is useful for debugging purposes.

However, it is cryptic and those who object to try for causing an implicit function return would probably object even more to some symbol doing the same thing. On the other hand one thing those same people might like is that it automatically rules out nested expressions and the like.

[mvndaai]

I have 2 main concerns. This eliminates the ability for error decoration and it always implicitly returns. I often return an error, but sometimes I just log it or continue in a loop.

[integrii]

@mvndaai Having this feature does not preclude the standard if err != nil { pattern. You could still use a control statement to decorate, retry, or whatever you like.

[mvndaai]

@integrii I agree that is doesn't stop the current pattern from working, but it does mean that there is another pattern.

My biggest issue with go errors is when I have if _, err := foo(); err != nil { and later decide that I need the variable what was _. I have to then refactor to

a, err := foo()
if err != nil {

Which is annoying to do and my function scope gets polluted with a long-living err variable.

I am worried adding a third way to handle errors would mean I would end up doing even more refactors.

[donaldnevermore]

The err is better than symbols. I can see it is an error at first sight.

[ianlancetaylor]

This is similar to other issues such as #32500 and #32601 which have been closed. This proposal does not have strong support, and will be cryptic for people new to Go. Therefore, this is a likely decline. Leaving open for one month for final comments.

[ianlancetaylor]

There were no further comments.