ag@cbmvax.commodore.com (Keith Gabryelski) (10/26/90)
In article <1893@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: >Surely you mean that if you don't know how to handle a specific recovery >(for some unspecified error type) it's still treated as failure? How do you handle undocmented return codes? In the case of close() and Gnu Emacs--aborting or ignoring are both wrong (the data in the file that was written is not up to date). The correct solution would be to warn the user and return upon request. But how do you know this before hand? What is reasonable to expect from a programmer? I system call that returns an error code that is undocumented was documented wrong AND when it does return an odd error IS in wrong. A programmer should not be required to handle such things. All bets are off if umask(2) returns -1 (ENOMEM). Pax, Keith -- ``[...] you twist and turn -- like a twisty turny thing.'' --Boyd Roberts Keith Gabryelski ag@amix.commodore.com
boyd@necisa.ho.necisa.oz (Boyd Roberts) (11/05/90)
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...''