Path: utzoo!utgpu!watserv1!watmath!att!att!pacbell.com!mips!sdd.hp.com!samsung!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.internals
Subject: Re: Undocumented Return Codes
Message-ID: <1913@necisa.ho.necisa.oz>
Date: 5 Nov 90 00:58:31 GMT
References: <1893@necisa.ho.necisa.oz> <15400@cbmvax.commodore.com>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 31

In article <15400@cbmvax.commodore.com> ag@cbmvax.commodore.com (Keith Gabryelski) writes:
>
>How do you handle undocmented return codes?
>

It depends on the context.  Basically there are only a small N failures you
can recover from (in a given situation).  For the others you just ignore
their error class.  After all, the operation still failed.

Failure is usually disaster.  The recovery procedure is usually fairly generic.

>
>All bets are off if umask(2) returns -1 (ENOMEM).
>

In more way than one.  When umask(2) fails you use perror(3) (or its
equivalent) to print a worthwhile message which says `I tried to
call umask and I go ENOMEM'.

The error return indicates failure.  It is the failure that's important.
Once you've recognised the failure, the reason is important.  From the
reason you may be able to recover (given a set of known error classes
and their respective recovery methods).

If you don't know how to recover you _must_ indicate the class of the error.
That way you have a pointer to the problem, rather than silence.


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''