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
> <golang-nuts@googlegroups.com> wrote:
>
>
> 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.
>
>> On Wed, Feb 16, 2022 at 11:12 PM Robert Engels <reng...@ix.netcom.com> wrote:
>> 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.
>
> --
> 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/CAEkBMfHHkcx_b%3DJhrbR6DORpUjuDUvJb1xdRTa3jJ2DXj%3DE7jA%40mail.gmail.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/F7D599FF-FD3B-4209-9824-BC394B3D6C35%40ix.netcom.com.
