error handling techniques?

[Pete Siemsen]

amodeo at dataco.UUCP (Roy Amodeo) writes:

>One solution to this is to use a stack of errnos and errparms instead of
>single global variables. It also helps to have a user definable error
>string that is saved in this stack. As the error gets passed up the call
>chain more information is added. If the main program chooses to abort,
>the entire error stack can be dumped giving a complete description of the
>error. Although this generates really nicely detailed error messages
>with very little coding trouble, I have not used it on any programs that
>have enough levels of function calling to make it really worthwhile.

I used exactly such a scheme on a project a few years ago.  It worked
very well, but meant that every subroutine call (this was FORTRAN)
took about 6 lines of code.  At any level, a subroutine could decide
to "handle" errors from below, or pass the errors on up (adding it's
own idea of what was wrong first).  Once we got used to the verbosity
(in C, macros would reduce this), we were impressed with how well it
worked.  Whenever an error occurred, you'd get a message something
like

GETREC: READ failed: illegal logical unit number
READFILE: unable to read record from file
COPYFILES: unable to read input file ABC.DEF
MAIN: unable to copy files

which is about as helpful as it gets.  This was one of the smoothest
software projects I have ever worked on.  Of course, there were only
five of us working on the code (for about 9 months), and we all agreed
on the error system before starting.  The customer was very pleased.

-- 
Pete Siemsen                         Pete Siemsen            siemsen at usc.edu
University of Southern California    645 Ohio Ave. #302      (213) 740-7391 (w)
1020 West Jefferson Blvd.            Long Beach, CA 90814    (213) 433-3059 (h)
Los Angeles, CA 90089-0251