Thanks Lance.
On Saturday, August 6, 2016 at 4:43:02 PM UTC+1, Ian Lance Taylor wrote:
>
> On Sat, Aug 6, 2016 at 5:50 AM, GoNutter <anewex...@gmail.com
> <javascript:>> 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.
