-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: error handling with orbail err #67955
Comments
Similar Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
@ianlancetaylor yes, thanks for linking these, I believe it's different because it only optimizes for the common cases, and doesn't allow having more scopes or blocks. Just a single error or implicit orbail with no arguments |
It took me longer than I'd like to admit to realize that I was supposed to read The use of "bail" as in "bail out" to mean "return early with an error" seems unusually casual and "slang-ish" compared to the rest of the language. I've heard on numerous occasions that words run together all in lower-case can be particularly hard to parse for those who have less experience with the English language, because they don't have as much vocabulary readily available to draw on when guessing where the word boundaries might be. I am a native English speaker who frequently encounters run-together words like this but yet I also struggled with this one, I think in large part because the verb "bail" is not a word I expected to encounter in this context. I think the use of a somewhat-ideosyncratic word and running it together with another word with no delimiters makes this case particularly tricky, but I'm curious to learn if I'm the outlier here. Aside from the keyword name I don't think I have any particularly strong reaction to this proposal either positive or negative. I wouldn't be upset if it were added to the language using a different word or symbol. However, it does seem like all of the other similar proposals were already rejected and I don't see any significant differences aside from the specific choice of keyword. 🤔 |
It doesn't look comfortable, you'll be guessing what value he's returning instead of confirming his return value. And modifying it to if requires truncating a line. |
Would it be a compilation error if you tried to use |
|
Hi! Thanks for taking the time. Definitely not an outlier. I agree maybe orbail isn't the most suitable keyword, I added couple of other suggestions like orfail, orelse, else return. |
Thanks for taking the time! Yes, 100% correct there is some sort of implicitness comes with bailing out which is specifying the error only and default the rest to zero value. I added a more explicit version where the user specifies all of the returns, and I would love to know what you think! |
Should be, yes. The compiler will need to check the return arguments as if it was the wrong return statement I added a more explicit version too where the user specifies all of the returns in his bail as well |
Yes, in the implicit suggestion it assumes the last return would be an error
Yes
Thanks for pointing that out! |
Code without an if is never good code, so be honest and use an if. err-handle is a fancy feature that only does what it is supposed to do by default, and there's no way to place breakpoints. |
This proposal is only for err handling by immediately returning the error to the caller(implicitly or explicitly). If the user wants to do more than that it explicitly mentions to use the if err check. For the breakpoint, It only allows one expression, the arguments for return - I'm talking about the explicit suggestion 1- |
In general, I like the idea of having a quick handling of errors when you only need to return the error. So you don't have to explicitly check But I have few suggestions on the proposal: On func mightFail() (string, error) {
...
}
func caller() error {
result := mightFail() orbail
}
func caller() error {
result := mightFail() orbail fmt.Errorf("something went wrong: %w", failure)
} |
If you are Shakyamuni, you would help anyone in difficulty. If you position yourself as a noble person, you will go and solve the difficulties that people need help with. |
Slightly OT: Again, an txt, err := http.Get() else return Error handling proposals that cover wrapping perpetually become too complicated. And, I don’t think that it is agreed upon in the Go community that wrapping is always a good idea in the first place, especially within a library. Does it make sense to write a proposal? |
The USP would be that – given that more complex proposals are notoriously rejected – one would propose a construct without any parameters. |
I really don't want to encourage anybody to write any more error handling proposals that are minor variations on existing ones. We just wind up making the same points over and over. txt, err := http.Get() else return Here are some questions I have that I've written for dozens of earlier proposals. My goal is not to tweak this proposal to answer these questions. It's to point out that we've seen and rejected a lot of error handling proposals.
|
(2) and (4) are addressed in in this issue. However, I am grateful for your point (3). Then, I refrain from it. |
This syntax is unlike anything else in Go, with an implicit return and no curly braces around a block. The proposal is very similar to #61750, which uses |
No further comments. |
Proposal for Error Handling in Go using the orbail Syntax
Introduction
Error handling is a critical aspect of software development, especially in a language like Go where explicit error handling is a core principle. This proposal introduces a small addition to the language,
orbail
, which aims to streamline and simplify error handling in Go code. Theorbail
keyword can be used to handle errors in a more concise and readable manner, potentially reducing boilerplate code and enhancing code clarity.Concept
The
orbail
syntax allows developers to chain error checks directly within expressions. When an error occurs,orbail
immediately handles itThis concept is inspired by the
or die
syntax in Perl and PHP, which allows for immediate error handling in a concise manner. Similarly,orbail
(or its alternatives such asorelse
ororfail
ororreturn
utilizing the||
operator) aims to provide a flexible and developer-friendly approach to error handling in Go. This change is totally opt-in, and also won't break existing code.Strategy
Optimize for the common cases that add visual noise to the code and cause the frustration which are
or
Suggestion 1: The user specifies all of the returns (explicit )
The user bails with return values
Which I believe is more aligned with go's philosophy and simpler for the compiler implementation
Example : wrapping an error
Before
After:
Suggestion 2: the user only specifies the error (implicit)
Coming from the name the user only care about failing or bailing with a specific error, so here a more implicit suggestion around specifying the errors only, which there is a consensus on having the error as the last return value of the function
Case 1: Implicit return
In its simplest form,
orbail
can handle errors immediately:If http.Get() returns an error,
orbail
will do an implicit return with zero values for all of the arguments, but the last one (the error) is returned implicitlyCase 2: Wrapping an error
You can also return a wrapped error if needed:
Example 1: Basic Error Handling
Before:
After:
Example 2: Custom Error Message
Before:
After:
Personal Opinions
||
given in the implicit case oforbail
ororfail
as it will look very weird and will not communicate the intentionorbail
ororfail
as it communicates the intention better thanorelse
none
or a single error Expression after the orbail (in case of the implicit) or a single return expression in the case of the implicit.Benefits
Implementation Details
To implement this syntax, the Go compiler would need to be extended to recognize and process the orbail keyword (or its alternatives). The following steps outline a high-level approach to the implementation:
orbail
,orelse
as valid tokens. (we can also reuse theelse
keyword to beelse
orelse return
ororelse return
if err!=nil
block: Replaceorbail
withif err!=nil
Conclusion
The proposed
orbail
syntax offers a streamlined and flexible approach to common scenarios in error handling in Go, reducing boilerplate code and improving readability. By allowing developers to handle errors directly with less typing it simplifies the coding process and enhances the overall developer experienceThe text was updated successfully, but these errors were encountered: