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.law...@gmail.com> wrote:
>
> 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
>
>> On Wednesday, 16 February 2022 at 12:50:16 am UTC+11 bargl....@gmail.com
>> wrote:
>> 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
>>
>
> --
> 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/be02eec5-34f6-429f-965f-30fe6b39893fn%40googlegroups.com.
--
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/14F50F22-CC7A-41B9-9D10-F2A664F6C85B%40ix.netcom.com.
