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: add functionality to remove repetitive if err != nil return #16225

Closed
losjr opened this Issue Jun 30, 2016 · 5 comments

Comments

Projects
None yet
7 participants
@losjr

losjr commented Jun 30, 2016

Great language but kind of tired of writing:

if( err != nil ){
return PrimaryData{}, err
}

Proposing something similar to 'defer' except with a condition where you declare the statement after the variable is defined. Using 'try' in the example but feel free to replace 'try' with your favorite exception handler like 'rescue' et al. If the condition in the 'try' is true the block executes. Currently, thinking the block should always have a return so it only executes once. Thinking the statement should be treated as if the compiler inserted it after every assignment of the variable(s) in the condition

func repeatErrReturn() (out User, err error) {
try( err != nil ){
   return User{}, err
}
... // real code
yeahRight , err = otherPkg.unreliable()
.. // more code
}

or

func repeatErrReturn2() (interface{},  error) {
var err
try( err != nil ){
   return User{}, err
}
... // real code
_ , err = otherPkg.buggy()
.. // more code and other 'err' assignments
}

@bradfitz bradfitz added the Proposal label Jun 30, 2016

@bradfitz bradfitz added this to the Unplanned milestone Jun 30, 2016

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Jun 30, 2016

This and similar ideas have been discussed many times in the past. Here is a recent discussion: https://groups.google.com/d/msg/golang-nuts/UwH5CreZPe4/xxI8gFsVBAAJ .

Make sure to read https://blog.golang.org/errors-are-values .

@beoran

This comment has been minimized.

beoran commented Jun 30, 2016

In languages such as snobol, icon and unicon, you could return from a function in a special way to indicate error or failure, and any such failure return would be automatically propagated recursively op the call stack unless the failure value is received as an additional return value. This would involve a new keyword, say "failure" for such a fail return.

But I realise that this is probably too "magical" for Go. Still, it is a useful feature in a higher level language.

@losjr

This comment has been minimized.

losjr commented Jun 30, 2016

@ianlancetaylor , Thanks for the article and the group link. The blog has a good point about how to use the language to minimize my stated annoyance.

@pciet

This comment has been minimized.

Contributor

pciet commented Jul 25, 2016

I think the error type needs to be used in currently uninvented ways before a new decenter error handling pattern would emerge.

@adg adg added the LanguageChange label Aug 29, 2016

@adg

This comment has been minimized.

Contributor

adg commented Aug 29, 2016

I don't think this is in the spirit of the language, and has been hashed out many times before. While there is probably room for a detailed proposal in this area, I'm declining this particular one.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.