error handling techniques?

[Richard Harter]

In article <1990Nov12.184217.25361 at elroy.jpl.nasa.gov>, alan at cogswell.Jpl.Nasa.Gov (Alan S. Mazer) writes:
> In article <238 at smds.UUCP>, rh at smds.UUCP (Richard Harter) writes:
> > This started out in comp.software-eng, which is where I posted to.  Alan's
> > comments showed up comp.lang.c.  I find this somewhat puzzling.  I have
> > redirected it back to comp.software-eng.

> Actually, I posted the original article to both newsgroups because C is the
> language I use most and because things can be done in C that may not be
> possible in all the languages represented by the readers of comp.software-eng.

Oh.  That makes sense.  My apologies for confusing the issue.

Continuing from your remarks.  There are actually a number of categories
of software to consider with different error handling issues.  For example,
there are application programs with human interaction, application programs
which are called by other programs, subroutine libraries called by a specific
set programs, and libraries which can called by arbitrary programs.  We can
talk about interface errors and internal errors.  An application program
may be mission critical in the sense that it must continue operating and do
the best that it can despite errors; conversely it may be mission critical
in the sense that it must not produce erroneous results.  It may not be
mission critical; in fact there may be an acceptable level of erroneous
behaviour.  And so on...  From this I would conclude that there are a
number of possible strategies.

One general remark on this topic that I would like to make is that it seems
to me that it is imperative that error handling philosophies be consistent
between components being put together.  For example a 'mission critical'
program should not use routines from a library that dump core or do
something erratic if there is a usage error.  This places strong constraints
on general purpose libraries; IMHO there should be strong constraints.
If a GPL routine or program is unsafe (i.e. it can behave in unpredictable
ways in response to errors in interface usage) it should be labelled as such.
-- 
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.