On Sat, Aug 6, 2016 at 5:50 AM, GoNutter <anewexplo...@gmail.com> wrote:
>
> I have a number of cases where I have to handle typed errors. I have been
> doing this previoiusly
>
> err :=SomeFunctionCall()
> if err != nil{
> switch e := err.(type){
> case sometype:
> //do something
> case someothertype:
> //do something else
> default:
> //do default
> }
> }
>
> However, it occurred to me that I can just do this...
>
> err :=SomeFunctionCall()
> switch e := err.(type){
> case nil:
> break
> case sometype:
> //do something
> case someothertype:
> //do something else
> default:
> //do default
> }
>
>
> I guess this will be less efficient because it will involve some reflection
> in cases where I imagine the initial check that error is not nil will be
> less expensive. Is this correct?
No, not really. The check for err == nil is pretty much the same as
the initial check in the type switch. There might be an extra branch
instruction in the type switch, I'm not sure, but I expect it would be
negligible in practice.
> Apart from this, is there any other reason that this would not be a
> recommended way to handle the nil error case?
It's more idiomatic Go to write err != nil, so other people reading
your code may find it a bit surprising. Only you can judge how
important that is for you.
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.
For more options, visit https://groups.google.com/d/optout.
