-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: spec: conditional return with return ?err? #70170
Comments
Instead of using the proposed ?err? syntax, you can achieve streamlined error handling using a helper function:
This approach maintains the explicit error handling pattern while reducing repetition through a reusable function. It keeps the code clear and aligns with Go's existing conventions. |
This has some similarities to the recent #70147. This turns what looks like a Therefore, this is a likely decline. Leaving open for four weeks for final comments. |
No further comments. |
Go Programming Experience
Intermediate
Other Languages Experience
C#, Java, JS
Related Idea
Has this idea, or one like it, been proposed before?
There have been many variations of error handling, proposing an error short circuit syntax such as
return?
, where the function will return if the last value being returned is an error and that error is not nil. Among the several issues that are had with the proposal is that a return with a question mark is a pretty small thing to notice with the human eye. Additionally, essentially codifying the conventional "error as the last return value" seems to be an issue. This issue hopefully avoids both of the above issues.Does this affect error handling?
Yes, see above.
Is this about generics?
No
Proposal
Add a special syntax where if a return value is of type error and it is wrapped in question marks (e.g. ?err?), then that return statement only returns if it is the last return in the function body OR the
err != nil
Language Spec Changes
See above
Informal Change
Let's take a simple function that contains a couple of error handling checks:
The above function is very simple, with only a couple of error cases, but it should be sufficient to demonstrate the change. Here is the revised version:
Of course there is not requirement that you must wrap the result of a function call with the question marks. The following would be allowed
Three notable features/limitations are:
return ?err?, user
is valid.return user, ?err1?, ?err2?
I feel that if this were used in conjunction with #70169, it would become incredibly valuable. But it is still valuable as a standalone.
Is this change backward compatible?
yes
Orthogonality: How does this change interact or overlap with existing features?
No response
Would this change make Go easier or harder to learn, and why?
It will make it slightly harder since there is a new syntax and an optional return
Cost Description
of course there is a cost related to implementation, and compilation.
Changes to Go ToolChain
No response
Performance Costs
No response
Prototype
No response
The text was updated successfully, but these errors were encountered: