-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: check / handle with extra arguments #68720
Comments
Thanks. As mentioned in #40432, one of the major reasons that the original check/handle proposal was rejected was that the distinction between |
This comment was marked as abuse.
This comment was marked as abuse.
This is fairly similar to the original check/handle proposal. It doesn't resolve the main issues with that proposal. Emoji voting is not in favor. 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#, JS/TS, Python, Ruby
Related Idea
Has this idea, or one like it, been proposed before?
I don't believe so, I'm pretty familiar with the history of error handling proposals and this is not quite like any that I've seen. It's inspired by this former proposal, with some intentional adjustments.
Does this affect error handling?
Yeah, sorry. But I think I've found a good approach that addresses the main concerns I've seen come out of error handling discussions:
Is this about generics?
No
Proposal
Here's an example:
As mentioned above, this is a minor redesign of this former proposal. Notable similarities and differences highlighted below.
Similarities
handle
andcheck
.handle
allows defining a custom handler for determining if the function should or should not return and how to modify the returned error.check
is used to invoke thehandle
code and pass the error, and eachcheck
is a potential termination point for the function.Differences
handle
check
check
statements are still used underneath each function call.errors.Wrap(...)
on every line.Language Spec Changes
handle
andcheck
keywordshandle
resembles a function but has slightly unique syntax and behaviorshandle
keyword replaces thefunc
keyword, it does not have a name, and it does not specify return valuesreturn
applies to the outer function and uses its return value signaturereturn
statement, which will allow execution to resume at thecheck
pointcheck
is syntactically the same as areturn
statementInformal Change
This approach allows you to define a reusable error handler at the top of your function, and then you can easily invoke it at each point that you check an error, which keeps the main function code clear and simple.
Is this change backward compatible?
I believe this would be backward compatible, I don't see any reason it shouldn't be.
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?
No response
Cost Description
No response
Changes to Go ToolChain
No response
Performance Costs
No response
Prototype
No response
The text was updated successfully, but these errors were encountered: