On Tue, Feb 15, 2022 at 5:49 AM Vojtěch Bargl <bargl.vojt...@gmail.com> wrote:
>
> my name is Vojta and I would like to join a error handling proposals 
> discussion and because I don't know what else to say I guess I will jump 
> right to it.
>
> I know everyone has his/her own opinion about this topic, which has its pros 
> and cons.
> And even though I think current solution is well-done I found myself smiling 
> when I browse through my or someone else's source code because of that very 
> well known reoccurring pattern:
> ```
> if err != nil { ... }
> ```
> Do not get me wrong but I think it is pretty ironic when you see reoccurring 
> pattern in context where you try to minimize these into more generalized form.
>
> I tried to read most issues on Github with error-handling label, but there 
> are just so many that in this point I am glad I found link to Error Handling 
> meta issue which summarize all important issues about this topic. I would 
> like to get your opinion about solution that I did not find in this 
> summarized list.
>
> I would like to get opinion of people that know little more about golang 
> itself and are able to provide "holes" in this solution. Feel free to point 
> them out, but please keep in mind that I may not be able to solve them alone. 
> Like I said, I just wanted to discuss this solution before I file official 
> issue proposal.
>
> Solution
> I got inspired with golangs `:=` operator that handles declaration and 
> assignment of variable. It's basically two operations in one. So what about 
> using something similar, like `?=`, that would assign variables and 
> additionally check if last variable (if error) is not nil?
>
> What I'm talking about is replace these lines:
> ```
> if value, err = ReturnValueAndErr(); err != nil {
>   goto Err
> }
> if otherValue, err = DeriveAnotherValueAndErr(value); err != nil {
>   goto Err
> }
>
> Err:
>   // handle errors
> ```
>
> with these lines:
> ```
> value, err ?= ReturnValueAndErr()
> otherValue, err ?= DeriveAnotherValueAndErr(value)
>
> error:
>     // handle error
> ```
>
> It's very short and seems idiomatic to golang and it's main feature is it 
> does not break the flow of thought that author tried to express. Error 
> handling itself is already defined (and used) feature - labels and name of 
> label is intentionally already known keyword to get the link between ?= 
> operator and error handling.
>
> There are few limitations though:
>
> variables needs to be declared before
> (I mean not really, but idea is to access assigned variables in label.
> so value, otherValue and err should be declared)
> label error must exists and serve only this purpose
> (compiler option could change the name for backward compatibility)
>
> So what do you say?
> Can you make it better?

The idea of doing an automatic goto on error is also an aspect of

https://go.dev/issue/32611
https://go.dev/issue/34140
https://go.dev/issue/37035

There is a subtle complexity to such proposals.  The current Go
language does not permit a goto statement if there are new variables
in scope at the goto label but not at the goto statement
(https://go.dev/ref/spec#Goto_statements).  But this is hard to avoid
with a scheme like the one presented here.  How do we handle that
while retaining backward compatibility?

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/CAOyqgcXs%2B-dYNHwmFfUO4eyPRkyBz-SXK%3DQdkcBvLNyCbRqFFQ%40mail.gmail.com.

Reply via email to