Closed smasher164 closed 3 years ago
This seems substantively the same as the last check proposal, except on the LHS instead of a magic expression on RHS. The reason the last proposal was rejected AFAICT was that it turned out that check messed up code coverage percentages deeply (ie a line will count as covered even with no testing of error handling!), and no one wanted to bite that bullet. This proposal is not sufficiently different to get past that limitation, so I don't think it has much chance of being accepted.
@carlmjohnson If line coverage is a blocker for error handling proposals, then I think it's fundamentally impossible for a language change that simultaneously removes the error handling boilerplate while making independent lines show up in a coverage report.
That being said, I'm sympathetic to the idea that coverage tools should show if an error path is exercised. Any coverage tool/instrumentation/report would have to accommodate operations within a single line (or at least special-case the check
).
Also when you refer to the previous check
proposal, do you mean the check
/handle
one, or the try
one? Unlike either of those, this proposal does not rely on a handler block and keeps the imperative style by annotating the LHS. It eliminates ambiguity around what happens when invoking a function that doesn't return an error as its last parameter.
func f() (error, error, int)
func g() (i int) {
check e1, check e2, v := f()
return v
}
desugars into
func g() (i int) {
e1, e2, v := f()
if e1 != nil {
return i
}
if e2 != nil {
return i
}
return v
}
@gptankit Feel free to draft a separate proposal for that idea, but it has been brought up before: https://github.com/golang/go/issues/33233
Defining built-in function carries the risks that it looks like a regular function call. Inspecting code that redefines returnOnError
would make it unclear that it's changing control flow.
One of the consequences behind this proposal is that an editor can highlight the check
keyword differently, signifying during an assignment that something different is going on.
This seems similar to #32500 #32601 #32884 #33150.
I don't understand why this requires named result variables.
Purely as a matter of style, the new use of check
seems to emphasize the error result, which tends to obscure the more important non-error code.
Hopefully the golang team will consider for an automatic error check. Something like in rust because
if err = call() {
return
}
is about 15% of the code I am working on.
By rough numbers we have:
if err = ... 583 occurrences if err := ... 176 occurances
multiplied by 3 lines of code it means 2277 LOC just to treat the errors with the same exact error handling pattern. The entire source code is 16095 LOC. The error handling is 14.14%
@ibudisteanu This has been discussed at great length elsewhere. A good starting point is #40432. Let's keep discussion on this issue focused on this specific proposal. Thanks.
@ianlancetaylor
This seems similar to #32500 #32601 #32884 #33150.
I can update my proposal to mention these. However,
I don't understand why this requires named result variables.
I should have explained this more in the original proposal, but when annotating the error result, the natural question to ask is "what happens when the error is non-nil?"
err
variable is shadowed. If we went this route, then named return values are still necessary, since they permit the naked return.err
in a new scope. This is the approach I preferred, since it provides the most flexibility around where the assignment can happen.Purely as a matter of style, the new use of
check
seems to emphasize the error result, which tends to obscure the more important non-error code.
Edit: This is a tradeoff made for readability. Anything less than a keyword, and the code might be too cryptic because the function exits early.
Purely as a matter of style, the new use of
check
seems to emphasize the error result, which tends to obscure the more important non-error code.
if you look at the code:
func printSum(a, b string) error {
x, err := strconv.Atoi(a)
if err != nil {
return err
}
y, err := strconv.Atoi(b)
if err != nil {
return err
}
fmt.Println("result:", x + y)
return nil
}
the error handling code tends to obscure the more important non-error code.
I think better error-handling
expr? // return if err
@qingtao One of the goals of this proposal is to make it more obvious to the reader that there are changes to control flow. This is why I chose a keyword over an operator. If you have an argument for using a ?
operator, please file separate proposal.
make it more obvious to the reader @smasher164 sorry, add extra keywords check vs? The purpose is the same. Not much help for reading.
@qingtao Clearly there is a subjective element to this. If you feel that strongly about it, please file a separate proposal.
That being said, on one hand @ianlancetaylor has stated that
check
seems to emphasize the error result
while you state that ?
and check
have the same level of readability. This is something that I presume will be decided through this review process.
return
and panic
, both of which use an identifier.Therefore, I would not argue that a keyword and ?
are the same.
Something nice about Go is that general errors are simply values, the language doesn't give them any special treatment. This feature would contradict that idea. If we are to solve error handling, I would like it to be a solution that doesn't give errors special treatment. I'm alright with this solution, though. It does look a bit strange without syntax highlighting, however. Maybe my eyes just have to get used to it.
the language doesn't give them any special treatment.
It kind of does though. The error
interface is a universal-scope lower-cased exported type.
the language doesn't give them any special treatment.
It kind of does though. The
error
interface is a universal-scope lower-cased exported type.
Right, when I say “special treatment” I mean “behaves differently from other values”. Such as in Java with being able to throw Throwables and automatically unfurl the stack, or (not quite as drastically) Swift where errors have a special “slot” for functions to return an error.
Currently, the Go spec does not have any “special treatment” for errors besides providing a universal interface for them. Using this interface is entirely optional, and the language itself doesn’t “encourage” its use in any way (ie special language features which only work on the builtin error
interface). I would like it to stay that way if possible. The standard library encourages its use, which (in my opinion) is good.
@deanveloper
the language doesn't give them any special treatment. This feature would contradict that idea.
I believe most of the error handling proposals fall into this category, so this flaw is not unique to this proposal.
I would like it to be a solution that doesn't give errors special treatment
There are generalizations of this proposal that could be applied to non-error values, but I want to keep this narrow in scope. For example, check
could be made to work with any interface
or even nillable
type.
However, I think even if errors were given special treatment, this is an example of a language evolving with the needs of users. Rather than introducing a type-level feature, we address the syntactic issue with a special form of assignment.
I suspect some might wonder how this proposal would interact with generics, where functions may start returning Result[T]
, defined as
type Result[T any] interface {
T | error
}
I believe check
can be extended when that time comes to apply to Result
values as well, as a form of destructuring assignment. But we should cross that bridge when we get to it.
Edit: One way I'm thinking about it is extending the definition of assignment to operate on errors. For pointers we have *p
, slices and arrays we have arr[i]
, check
is merely an operator defined on errors during assignment.
I believe most of the error handling proposals fall into this category, so this flaw is not unique to this proposal.
Yeah, pretty much all of them do. Not quite all though, however the ones that don't aren't very elegant... Not sure how possible it would be to do successfully.
There are generalizations of this proposal that could be applied to non-error values, but I want to keep this narrow in scope. For example, check could be made to work with any interface or even nillable type.
I think it would be quite strange (at least with the spelling check
) for this to apply outside of errors. I'm not trying to say it should by any means. I just think that a "perfect" feature wouldn't treat errors as special values. Go doesn't need to shoot for perfect, though.
I believe check can be extended when that time comes to apply to Result values as well, as a form of destructuring assignment. But we should cross that bridge when we get to it.
This would be really cool provided that some kind of Result
would end up being used. However a benefit of a system which doesn't treat errors specifically would work with Results as well
I almost always wrap my errors with a short message. In the example above I would have
func printSum(a, b string) error {
x, err := strconv.Atoi(a)
if err != nil {
return errors.Wrap(err, "parse a")
}
y, err := strconv.Atoi(b)
if err != nil {
return errors.Wrap(err, "parse b")
}
fmt.Println("result:", x + y)
return nil
}
check
keyword looses that option. So I would have to drop my nice error descriptions or I wouldn't be able to use that proposal.
I don't also see any problem with these ifs. With empty lines it looks pretty clear what's happening here.
@nikandfor
This proposal isn't meant to replace if err != nil
in every context, but in most usages.
That being said, typically the context associated with a returned error is scoped at the function level, and not at each return. In the example you gave above, parse a
and parse b
provide different context for each parameter name. So while this would be a place where if err != nil
makes sense, I question the value gained from referring to the parameter name in the error message here. Why isn't something like parse: strconv.Atoi: parsing "asdf": invalid syntax
good enough?
Would the check
return the err
unaltered, or would it wrap the error with information about where the error occurred?
@leighmcculloch
check
returns the err
unaltered, so location information is lost. However, because defer
red functions can modify return values, you can still add context (just not at the granularity of which line the error came from).
It occurs to me that if something like check
is to be added it must handle what for many is the most common case of error handling, where the error is wrapped and appropriately annotated. How to do that though is unclear to me.
Maybe something like the below, or that achieves the same effect as the below, but better because this seems not great:
x, check("annotation %s: %w", someInput, err) := f()
it must handle what for many is the most common case
I don't know that it's true that adding context to every return is the most common case of error handling. I think if per-return context is needed, one would want to draw attention to it, and the two extra lines of control flow serve that purpose.
Maybe something like the below
https://github.com/golang/go/issues/33150 and https://github.com/golang/go/issues/32500 suggest something similar. They are not very specific on evaluation order, and overlap with the work that error wrappers like fmt.Errorf
do. Can the wrapper be any arbitrary function? Does it need to accept an argument of type error (as the first argument)? I'd be interested to see variants of this proposal that allow one to wrap at the assignment.
Otherwise, writing the function so that in most cases, the context can be provided at the function-level would allow one to reuse mechanisms like defer
for adding context.
As noted above, this is similar to previous proposals that were not accepted. It adds a new keyword, so it is not backward compatible. Based on that and the discussion above this is a likely decline. Leaving open for four weeks for final comments.
Based on the upvote/downvote ratio, I can understand that this proposal is likely to be declined. However, for future reference, I'd like more clarity on why this language change is not considered backwards compatible. Although a new keyword is introduced, the keyword is not usable in a context where it is ambiguous. Typically, keywords are used in statements, and are not available on the left-hand side of an assignment. Moreover, there is no ambiguity with other identifiers on the left-hand side of an assignment, because currently it is not legal to have two identifiers next to each other on the left-hand side that are only separated by whitespace.
By definition, a new keyword is not backward compatible. As the language spec says, a keyword may not be used as an identifier.
Reading more closely, I see that although you say that check
is a keyword, you mean something else: it is an identifier that has a special meaning in certain circumstances. Sorry for missing that point.
There isn't anything like that in Go today. In Go identifiers are always defined, or not, in a given scope. The approach you describe raises a different kind of concern: identifiers that only sometimes have a special meaning can be confusing for programmers, because minor changes can have surprising repercussions.
identifiers that only sometimes have a special meaning can be confusing for programmers, because minor changes can have surprising repercussions
Understandable. I can imagine it being confusing for a programmer to see that
x, check err := foo()
and
x, check := foo()
have different semantics, although an editor highlighting check
as a keyword would help. I will mention this flaw in the proposal text.
No change in consensus.
Would you consider yourself a novice, intermediate, or experienced Go programmer? Experienced
What other languages do you have experience with? C, C++, Assembly, Java, Python, Javascript, SML, Rust, Racket, Shell, SQL, LATEX.
Would this change make Go easier or harder to learn, and why? It would make Go harder to learn, since it is one more choice the user must make before handling an error. Hopefully though, it becomes the default. It is also the first instance of an identifier being a keyword only in certain contexts. This could be confusing in cases where forgetting to bind
check
to a variable turns it into a variable.Has this idea, or one like it, been proposed before? The proposal that comes closest to this idea is #42318. Other similar issues are #32500 #32601 #32884 #33150.
If so, how does this proposal differ? **1. #42318 uses a special character to mark the variable, whereas this proposal uses a new keyword.
42318 returns the zero value for unannotated variables, whereas this proposal relies on named return values to do the heavy lifting.
42318 allows substituting a handler function for the annotation, whereas this proposal makes use of defer for handlers.
32500 is far too broad in that it suggests panics, returns, and special operators, but doesn't specify evaluation order.
32884, #32601, and #33150 do not assign an identifier to the variable on the left-hand side, and don't specify how that variable is mapped to the return value, leaving us to assume that it relies on some convention around the last return value being an error. They also use an operator instead of a keyword, which obscures the early exit that can happen.
33150 introduces a separate mechanism for wrapping an error.**
Who does this proposal help, and why? **1. It helps authors of Go source code avoid three extra lines of code in the common case where they early exit on an error.
What is the proposed change? **1. A new keyword
check
is introduced.error
.check
is a normal identifier. This keeps the change backwards-compatible to Go1.is equivalent to the following code:
Is this change backward compatible? Yes
Show example code before and after the change. Before
After (normal return) https://play.golang.org/p/nYugCFk4o-Z
After (return with additional context) https://play.golang.org/p/zaTO6KjUXmF
After (with a hypothetical error wrapper) https://play.golang.org/p/LQCn_Nj_I4C
What is the cost of this proposal? (Every language change has a cost).
if err != nil
.Can you describe a possible implementation? I have a partial implementation on https://github.com/smasher164/check-go. I haven't had time to finish changes to the typechecker, so all it does right now is tokenize and parse the
check
keyword on the LHS of an assignment.Does this affect error handling? Yes
Why are named return values necessary? When annotating the error result, the natural question to ask is "what happens when the error is non-nil?"
Edit:
check
being a context-dependent keyword is different from the way identifiers work today, and could potentially be confusing to work with.