Functions returning Error codes or actual info

Richard A. O'Keefe ok at goanna.cs.rmit.oz.au
Tue Sep 11 15:29:03 AEST 1990


In article <772 at babcock.cerc.wvu.wvnet.edu>,
vrm at cathedral.cerc.wvu.wvnet.edu (Vasile R. Montan) asks
about returning error information.

Had you considered doing it with functions?

Example:  UNIX System V <math.h> library; there is a function
matherr() which each of the math functions calls when it detects
an error.  matherr() is given a description of the error and can
return a corrected value or do whatever you like.  If you don't
define your own matherr(), the loader picks up a default version
from "libm.a".

Example:  the HP-UX extension to UNIX system calls; you can
register an error handling function, and whenever a system call
is about to set errno and return an error value it will call
your function instead, passing it the value it was going to
assign to errno and a <varargs> pointer to the argument list of
the system call, and the system call number.  Your function can
do anything you like, including correcting the arguments and
retrying.  (I implemented this for SunOS 3.2; the basic trick
was that all the system calls branch to 'cerror:' to report
errors, and all that had to be done was to plug in a different
cerror.)

Example:  the way Algol 68 handled transput errors.  Files in
Algol 68 were implemented as records some of whose fields were
functions for handling error or other conditions.  You could
assign your own functions to these fields.  An error having been
detected, the function would be called with the file and any
other information available about the error as parameters.

Functions are _much_ more flexible than returning error codes.
-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.



More information about the Comp.lang.c mailing list