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

Open
integrii opened this issue Jul 1, 2019 · 8 comments

Comments

@integrii
Copy link

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

@gopherbot gopherbot added the Proposal label Jul 1, 2019

@networkimprov

This comment has been minimized.

Copy link

commented Jul 2, 2019

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 comment has been minimized.

Copy link
Contributor

commented Jul 10, 2019

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

@alanfo

This comment has been minimized.

Copy link

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.

@mvndaai

This comment has been minimized.

Copy link

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.

@integrii

This comment has been minimized.

Copy link
Author

commented Jul 20, 2019

@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

This comment has been minimized.

Copy link

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.

@DongchengWang

This comment has been minimized.

Copy link

commented Jul 20, 2019

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.