Xref: utzoo comp.software-eng:4430 comp.lang.c:33722
Path: utzoo!attcan!uunet!ogicse!ucsd!sdd.hp.com!elroy.jpl.nasa.gov!news
From: alan@cogswell.Jpl.Nasa.Gov (Alan S. Mazer)
Newsgroups: comp.software-eng,comp.lang.c
Subject: Re: error handling techniques?
Message-ID: <1990Nov12.184217.25361@elroy.jpl.nasa.gov>
Date: 12 Nov 90 18:42:17 GMT
References: <1990Nov2.205831.23696@elroy.jpl.nasa.gov> <234@smds.UUCP> <238@smds.UUCP>
Sender: news@elroy.jpl.nasa.gov (Usenet)
Organization: Image Analysis Systems Group, JPL
Lines: 46
Nntp-Posting-Host: cogswell.jpl.nasa.gov

In article <238@smds.UUCP>, rh@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.

Meanwhile, Alan Findlay writes:

> In article <234@smds.UUCP>, rh@smds.UUCP (Richard Harter) writes:
> > 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

> This kind of approach involves either a purist conception about what is an
> error or a library package which has such a narrow area of application that
> applications using the package have highly predictable requirements.

Actually, I assume (perhaps I'm wrong) that the author is not describing a
library package, although such an approach might be appropriate in libraries
for very critical applications.  There are some times when to not do it at
all is much better than to do it wrong.

> The problem for the supplier of a (practical) general purpose library package
> is that what may be regarded an error by one application is not so regarded
> by another.

Excellent point and the best reason why a lot of simple schemes are really
inadequate.

> The subject line is "error handling techniques" and the original posting
> requested information about techniques for library packages.  For the reason
> given above this is better called "exception handling techniques".

Actually, the original posting solicited information about techniques for large
systems (principally turn-key type applications) as well as libraries.  And it
was supposed to address regular user errors (application passes bad parameter
to function library, for example) as well as horrible unexpected system
errors.  It's unclear to me how suitable an exceptions approach is to the
former case, although I haven't thought about it a lot.
-- 

-- Alan			       # My aptitude test in high school suggested that
   ..!ames!elroy!alan	       # I should become a forest ranger.  Take my
   alan@elroy.jpl.nasa.gov     # opinions on computers with a grain of salt.