tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: fixing compat_12 getdents

>> Then people get upset because they say "function foo() isn't allowed
>> to set errno to 'bar'".
> Then how do you sanely write error handling routines?  The error
> returns form part of the interface and should be documented as such.

There are two kinds of error returns.

There are error returns which are expected and which you have specific
handling for.  EEXIST when trying to open a lockfile O_CREAT|O_EXCL.
EWOULDBLOCK when trying to read from a nonblocking socket.  ECHILD from
waitpid() in a reap-all-dead-children loop.  That sort of thing.

And then there are "other" error returns, the ones which mean
"something went unexpectedly weird".  EPERM when trying to kill(2) a
worker process you forked and which doesn't exec.  EFAULT when
read(2)ing into what you thought was memory with static storage
duration.  That sort of thing.

The first kind of error returns have to be specifically coded for in
any case.

The second kind of error return rarely can provoke anything but a
cough-and-die response.  You can try to make it an orderly
cough-and-die, but such errors usually indicate that the code's
underlying assumptions have been violated and thus are a bit like a
kernel panic in that you can't do more than best-effort.  There's
little point trying to enumerate all possible errors in such cases,
especially since your code will inevitably do _something_ if it gets an
errno it's not expecting, so it really should do something sensible.
If nothing else, eventually it'll be built/run on a system that's added
a new errno as a possible return from that call.

The manpages (or local equivalent) should, of course, always describe
all possible returns, if only for the benefit of someone trying to
figure out where things went wonky.  But it's pretty rare to actually
handle them all as errors of the first type - I don't think I've ever
either done that or seen it done, possibly excepting cases where that
set is empty (getpid(), _exit(), etc).  (Admittedly, manpages, NetBSD
or not, often don't actually meet this ideal.  But that doesn't make it
any less of a good ideal.)

So, I think the "how to sanely write error handling routines" issue is
spurious.  Such code always has, de-facto if not intended, some kind of
catchall behaviour.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML      
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index