Yey another Error Handling proposal

[Vojtěch Bargl]

Hi, 

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?

Cheers,

Vojta

[Ian Lance Taylor]

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

[Corin Lawson]

Hi Vojta,

Can you please provide some real world examples (e.g. link to open source project) or a code style guideline that promotes the use of that pattern of using a goto?  I don't believe that it is idiomatic Go.  Personally, I can count on one hand the number of times I've seen the usage of goto in Go; be it 'in the wild' or otherwise.

I appriciate the leg work that you've done to get to this point, I can't honestly say I've reviewed the existing error handling proposals.  I imagine it's a hot topic!  I am not the gatekeeper of what is and is not idiomatic Go (I'm not sure anyone is!)  But can't say I share your experience; when I read and write code in my workplace, a lot of the error handling involves logic specific to the call the produced the error (e.g. wrapping the error) or a simple naked return.  I just don't see the value proposition at this time.

Cheers,

Corin

[Robert Engels]

Using goto for error handling in C is very common. See the Linux kernel. 

On Feb 16, 2022, at 3:07 PM, Corin Lawson <corin....@gmail.com> wrote:

Hi Vojta,

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/be02eec5-34f6-429f-965f-30fe6b39893fn%40googlegroups.com.

[Axel Wagner]

This is golang-nuts, though. Not C-nuts. Go's goto statement is significantly different from C's (see Ian's earlier response). And using it for error handling in this manner is extremely uncommon.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/14F50F22-CC7A-41B9-9D10-F2A664F6C85B%40ix.netcom.com.

[Robert Engels]

I don’t disagree. It is used in C because they don’t have exceptions so you need centralized handling.  Go can be viewed as similar in that respect - but with some extra limitations and additions. 

On Feb 16, 2022, at 4:53 PM, 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHHkcx_b%3DJhrbR6DORpUjuDUvJb1xdRTa3jJ2DXj%3DE7jA%40mail.gmail.com.

[Ian Lance Taylor]

On Wed, Feb 16, 2022 at 3:40 PM Robert Engels <ren...@ix.netcom.com> wrote:
>
> I don’t disagree. It is used in C because they don’t have exceptions so you need centralized handling. Go can be viewed as similar in that respect - but with some extra limitations and additions.

I'd say that the main reason that people don't need to use goto for
error handling in Go is that Go has the defer statement.

Ian

[Robert Engels]

That was the “addition” I was referring to. The defer covers resource cleanup on errors but it doesn’t handle error enrichment.

> On Feb 16, 2022, at 6:37 PM, Ian Lance Taylor <ia...@golang.org> wrote:

> --
> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVhUkC3sK%3D2yrVQKvs_osz89fyPbdem2AWH22po2_neWQ%40mail.gmail.com.

[Robert Engels]

I think an “on error goto” construct coupled with defer would be a capable error handling system. It would eliminate a lot of boiler plate and duplicative code.

> On Feb 16, 2022, at 6:50 PM, Robert Engels <ren...@ix.netcom.com> wrote:
>
> That was the “addition” I was referring to. The defer covers resource cleanup on errors but it doesn’t handle error enrichment.

[Ian Lance Taylor]

On Wed, Feb 16, 2022 at 4:54 PM Robert Engels <ren...@ix.netcom.com> wrote:
>
> I think an “on error goto” construct coupled with defer would be a capable error handling system. It would eliminate a lot of boiler plate and duplicative code.

See https://go.dev/issue/37035.

Ian

[Robert Engels]

I think what the commentary glosses over is the ability to set the on error once at the top. I would also make it a simple branch.

Still, as suggested there it doesn’t offer much.

I am more concerned about stack traces and the like and that could be done more simply.

> On Feb 16, 2022, at 7:29 PM, Ian Lance Taylor <ia...@golang.org> wrote:

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVYru0-_dP1vxzgB9arexccSCVxYzO-pSfEMRT8yX7GCA%40mail.gmail.com.