Re: question on common error-handling idiom

[linux-os]

On Tue, 2 Nov 2004, Jan Engelhardt wrote:

> > There's something I've been wondering about for a while.  There is a lot of code
> > in linux that looks something like this:
> >
> > err = -ERRORCODE
> > if (error condition)
> > 	goto out;
>
> That's because there might something as:
>
> err = -EPERM;
> if(error) { goto out; }
> do something;
> if(error2) { goto out; }
> do something more;
> if(error3) { goto out; }
>
> Is shorter than:
>
> if(error) { err = -EPERM; goto out; }
> do something;
> if(error2) { err = -EPERM; goto out; }
> do something more;
> if(error3) { err = -EPERM; goto out; }
>
>
> > Is there any particular reason why the former is preferred?  Is the compiler
>
> To keep it short. Because it might have been worse than just err =xxx:
>
> if(error) {
>    do this and that;
>    and more;
>    even more;
>    more more;
>    goto out;
> }
>
> Repeating that over and over is not that good. So we wrap it a little bit to do
> a "staircase" deinitialization:
>
> err = -EPERM;
> if(error) { goto this_didnot_work; }
> ...
> err = -ENOSPC;
> if(error) { goto that_didnot_work; }
>
>
> this_didnot_work:
>  all uninitializations needed
>
> that_didnot_work:
>  all other uninit's
>
>  return err;
>
>
> So to summarize, it's done to reduce code whilst keeping the error code around
> until we actually leave the function.
>
>
> My ˙˙ 0.02!
>
>
> Jan Engelhardt
> --
> Gesellschaft f˙˙r Wissenschaftliche Datenverarbeitung
> Am Fassberg, 37077 G˙˙ttingen, www.gwdg.de

I think it's just to get around the "uninitialized variable"
warning when the 'C' compiler doesn't know that it will
always be initialized.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by John Ashcroft.
                 98.36% of all statistics are fiction.