Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

integrii opened this issue Jul 1, 2019 · 9 comments
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal Proposal-FinalCommentPeriod v2 A language change or incompatible library change


Copy link

integrii commented Jul 1, 2019

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
@gopherbot gopherbot added this to the Proposal milestone Jul 1, 2019
@ianlancetaylor ianlancetaylor added v2 A language change or incompatible library change LanguageChange labels Jul 2, 2019
Copy link

This has been suggested many times. See #32500 and

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

Copy link

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

Copy link

alanfo commented Jul 10, 2019

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.

Copy link

mvndaai commented Jul 18, 2019

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.

Copy link

@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.

Copy link

mvndaai commented Jul 20, 2019

@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.

Copy link

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

Copy link

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.

Copy link

There were no further comments.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal Proposal-FinalCommentPeriod v2 A language change or incompatible library change
None yet

No branches or pull requests

8 participants