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 <https://github.com/golang/go/issues/40432> 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.
