Xref: utzoo comp.software-eng:4397 comp.lang.c:33383
Path: utzoo!utgpu!watserv1!watmath!att!att!linac!uwm.edu!zaphod.mps.ohio-state.edu!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: error handling techniques?
Message-ID: <1990Nov2.205831.23696@elroy.jpl.nasa.gov>
Date: 2 Nov 90 20:58:31 GMT
Sender: news@elroy.jpl.nasa.gov (Usenet)
Organization: Image Analysis Systems Group, JPL
Lines: 33
Nntp-Posting-Host: cogswell.jpl.nasa.gov

I'm interested in what approaches people use for error handling, particularly
in general purpose function libraries and large software systems.  If someone
can reference a text or article, that would be good.  

Meanwhile, to give an example of the type of stuff I'm thinking of, here are
some examples.  Say you're writing a function library.  When you detect an
error (the distinction between user and internal errors is ignored here) you
can

1. Set an error code (similar to errno in Unix) and return -1, leaving the
   application to check for specific errors or print out one of a supplied
   set of messages.
2. Call an application-specified error handler, and if none, call a default
   error handler.
3. Print out a message from the package.  (Where this should be displayed
   and how is also a factor.  It may not be possible to write to the user's
   terminal.)

Similarly, say an application discovers that it has some internal error.
Should it

1. Print a message and dump core.
2. Save some transparently-maintained log of user actions to disk along with
   a message indicating what's happened.
3. Provide a traceback of function calls and ask the user whether or not to
   continue.

What other approaches are there?
-- 

-- 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.