error handling techniques?

[Bob Martin]

In article <1990Nov2.205831.23696 at elroy.jpl.nasa.gov> alan at cogswell.Jpl.Nasa.Gov (Alan S. Mazer) writes:
>I'm interested in what approaches people use for error handling, particularly
>in general purpose function libraries and large software systems.  If someone

Alan:

In a large software system the number of places where the code can
detect errors can range into the tens of thousands.  Every call to
malloc should be checked, every IO operation, every place where 
something can go wrong should be checked...  This leads to an 
enormous amount of error checking and error messages.

What I have done in the past to cope with this is to create an
ErrorLog function which will write single line error messages into
an error log file.  The messages consist of the time, process id, and
three numbers.  mod,loc(param).  <mod> is a unique number which
identifies the module in which the error occured.  (by module I
mean .c file.)  <loc> is a number unique to that modules which
identifies the specific call the the ErrorLog function.  Thus if
a module can detect 20 errors, it will do so with 20 separate
<loc> numbers.  Errors of similar types should _not_ use the
same <loc>!   <param> is a piece of useful information (if any)
which can be logged with the error.  For example, when a malloc
returns NULL, I usually put the size that I was attempting to
malloc in the <param>.  errno would be useful in <param> when
appropriate....

Every hour I close the current error log file and open a new one.
At the end of the day I compile then into a summary and eyeball
them to see if anything horrible went wrong.  Software can be written
to automatically scan these logs to see if there are critical errors.

							Hope this helps.
							I welcome discussion.

----------------------------------------------------------------------
R. Martin
rmartin at clear.com
uunet!clrcom!rmartin
----------------------------------------------------------------------