error handling techniques?

[Richard Harter]

In article <1990Nov3.153643.26368 at clear.com>, rmartin at clear.com (Bob Martin) writes:
> 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

	[See the referenced article, which is commendably well written.]

In our key product, which we assume is mission critical for our users,
we take the strong view that any trapped error is a fatal error.  We try
to arrange that the software fails gracefully and that it produces as
much information about the error as possible.  Our view is that the software
should not fail, so we don't put any bugs in the code. :-)  Seriously,
here are some of the techniques used:

The code is liberally sprinkled with error checks.  Failed validity
checks are fatal; they generate a call to a universal error handler.  
The error handler generates an error report (if possible) and exits.
The code maintains a history of the last 128 function calls in a circular
buffer; this information is dumped in the error report.  Each error type
has its own message number.  System utilities (e.g. storage allocation
and file I/O) are wrapped; the wrappers have their own error service
reports.  Other information (ERRNO where relevant, for example) is
included.  The general view is that a failure is a bug; they aren't
supposed to happen.  If a failure should indeed happen, we want as much
information as possible to find and eliminate the bug.

I would like to see more contributions on this topic.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.