Some thoughts:
The "try proposal" and some others identified and solved two problems:
a. The verbosity of using a full if statement to check error values
b. The verbosity of applying wrapping and other error handling logic to
every place where an error is returned
This proposal only addresses Problem A. Maybe that's okay, because it seems
like addressing Problem B often leads to complicated control flow issues.
I do like that this proposal doesn't treat errors in a special way. I could
imagine it could be useful when checking if a key is in a map, for example.
value, ok := myMap["value"]
returnif !ok, errors.New("Oh no! Missing key 'value'!")
Another thought: Should returnif allow a statement before the boolean
expression like if does?
returnif value, ok := myMap["value"]; !ok, errors.New("Oh no!")
That could make code more compact but looks very busy to me. My first
impression is that this shouldn't be allowed.
I think I would be okay with reading and writing code like this. The level
of complexity here is certainly lower than other proposals, although the
value is arguably lower as well since it doesn't solve as many problems.
I'll defer to others here.
On Mon, Nov 9, 2020 at 1:52 PM Jeremy French <ibi...@gmail.com> wrote:
> Hm, yep. Very similar. Interestingly, the only cohesive objections I can
> see in those threads are to the minor details that are different from what
> I'm saying. Still, though - at least the idea has been presented before.
>
> Jeremy French
> 607-444-1725
>
> On Mon, Nov 9, 2020, 2:57 PM Ian Lance Taylor <i...@golang.org> wrote:
>
>> On Mon, Nov 9, 2020 at 11:20 AM Jeremy French <ibi...@gmail.com> wrote:
>> >
>> > First, the caveat. I know error handling is a long-standing
>> discussion. I know there has been lots of debate on error handling, and it
>> can seem like there are no more new ideas to be had on the topic. And I
>> have looked at several/most of the most popular proposals, and there are
>> quite a few that bear similarity but are critically different in important
>> aspects to this proposal. If this has been proposed before with the same
>> effective fingerprint, I haven't been able to find it after several hours
>> of due diligence. I'm interested in hearing any and all (well-reasoned)
>> thoughts on the matter, but if there's a flaw in my logic, I don't see it
>> yet.
>> >
>> > In short, the proposal is to create a conditional return statement,
>> e.g. "returnif" of the form:
>> > returnif [bool], [returnvalue],...
>> >
>> > This is syntactic sugar for:
>> > if [bool] {
>> > return [returnvalue],...
>> > }
>> >
>> > of which, the immediate benefit is:
>> > returnif err!=nil, err
>> >
>> > or alternatively:
>> >
>> > returnif myErrorChecker(err), myErrorWrapper(err, "Some text.")
>> >
>> > Here's my reasoning. Go Error Handling in is current form is extremely
>> correct, precise, explicit, and clear. All very good things. Really the
>> only problem with it is the repetitious verbosity. A programmer's
>> instinctive reaction to repetitious verbosity is to wrap it in a function.
>> The infamous "if err != nil {return err}", although repetitious and
>> ubiquitous, cannot effectively be encapsulated to "return
>> someErrorChecker()", because the return statement is unconditional. Once I
>> start a statement with return, nothing I can do later in the statement or
>> within a called function can change whether or how that return alters flow
>> control. This, I think, is the quintessential problem with the current
>> error handling methodology. This proposal addresses that without
>> sacrificing any of the good things about error handling in Go. Error
>> handling is still explicit. Errors can still be treated as values. Proper
>> error handling and annotating is blessed but optional. The behavior of
>> defer is unaffected. It is still simple to understand, and easy to read.
>> And it's entirely backwards compatible.
>> >
>> > Also, while the most obvious benefit is in error handling, this is not
>> technically just an error handling solution. It is completely unopinionated
>> on the type of values it returns, or whether they qualify as an error or
>> not. I can foresee enterprising gophers finding other uses for this
>> keyword, and quite possibly even new useful design patterns could emerge as
>> a result.
>> >
>> > Possible Objections:
>> >
>> > It could be seen to violate the "one way to do things" principle.
>> However,
>> >
>> > It violates this rule much less than almost all of the other proposals
>> for error handling.
>> > If, under the covers, it's just code substitution, then there's still
>> only one actual avenue of execution in the compiled objects.
>> > There is precedent for this type of shortcut when the benefits are so
>> widespread and the sugar improves readability. For example,
>> > } else if isTrue {
>> > doSomething()
>> > }
>> > is sugar for
>> > } else {
>> > if isTrue {
>> > doSomething()
>> > }
>> > }
>> >
>> > "It's just a variation on other existing proposals."
>> >
>> > This proposal avoids or addresses all the objections listed in the
>> error handling meta issue #40432, and as such, may be a variation, but
>> varies sufficiently to create a different result set.
>> > From the meta issue:
>> >
>> > The check/handle proposal.
>> >
>> > One major reason this was rejected was a lack of clarity between handle
>> and defer.
>> >
>> > The try proposal.
>> >
>> > One major reason this was rejected was the additional flow control: a
>> complex expression using try could cause the function to return. Go
>> currently has no flow control constructs at the expression level, other
>> than panic which does more than just return from a function.
>> >
>> > Special characters, often ! or ?, that insert an error check in a
>> function call or assignment.
>> >
>> > These are typically rejected because they are cryptic. Often a single !
>> or other character leads to a change in flow control.
>> >
>> > Simplifications of if err != nil, to reduce boilerplate.
>> >
>> > These are typically rejected either because they don't reduce the
>> boilerplate enough to make it worth changing the language, or because they
>> are cryptic.
>> >
>> > What about edge cases? How to handle else clauses or additional
>> conditional logic based on error type etc.?
>> >
>> > It's my belief that else clauses too rare to justify additional
>> syntax. If you need an else/else if clause, you can use the existing
>> syntax and lay out your conditionals on more lines. Also - you know - any
>> code after a return statement is essential an else clause anyway.
>> > By making [bool] an expression, any additional logic may be handled by
>> the programmer in a determinant function that returns a boolean. This puts
>> this type of flow control in the hands of the developer.
>> > The short statement currently available with if and for statements (if
>> err:=doSomething(); err != nil) could be implemented in a similar fashion,
>> but my personal vote would be to disallow it, as most of the simplicity and
>> clarity of this proposal could be lost down that rabbit hole.
>> >
>> > I believe the most critical difference between this proposal and
>> previous ones is that this proposal addresses the core issue more
>> directly. The central problem to the current error handling methodology is
>> not actually specific to error handling. That's just where it's most
>> visible. The core problem is essentially the fact that a child function
>> cannot affect the conditional return of a parent function (barring further
>> conditional logic), even with explicit permission by the parent function.
>> This is not true with any other form of flow control. This is why the
>> current methodology feels wrong to developers, because they are disallowed
>> from encapsulating repetitious logic in a way that is consistent with other
>> flow control statements.
>> >
>> > Anyway, that's my argument. If anyone knows of a previous proposal
>> that this duplicates, and/or knows why that one didn't/couldn't work, I'd
>> be grateful for the explanation.
>>
>> For the record, similar but not quite identical:
>>
>> https://github.com/golang/go/issues/21161#issuecomment-366766924
>> https://github.com/golang/go/issues/32811#issuecomment-508776641
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2Bj6mhDjFAjpQTcpA3oJfwFKUYdhNn-1jB39FiYoe6nspUTg2g%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CA%2Bj6mhDjFAjpQTcpA3oJfwFKUYdhNn-1jB39FiYoe6nspUTg2g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1RXATObiH-Lx_ZUQXqtT6DyJdR%3Dk9dbg-1KaMNoDL_wA%40mail.gmail.com.
