Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jarthur!uunet!cadence!shamu!baeder
From: baeder@shamu.cadence.com (D. Scott Baeder; x299)
Newsgroups: comp.software-eng
Subject: Re: error handling techniques?
Message-ID: <1990Nov15.162355.23151@cadence.com>
Date: 15 Nov 90 16:23:55 GMT
References: <1990Nov2.205831.23696@elroy.jpl.nasa.gov> <1990Nov3.153643.26368@clear.com> <286@dcsun21.dataco.UUCP> <28078@usc>
Sender: usenet@cadence.com (USENET News)
Reply-To: baeder@cadence.com
Organization: Cadence ACAE Division
Lines: 32

In article <28078@usc>, siemsen@sol.usc.edu (Pete Siemsen) writes:
|> amodeo@dataco.UUCP (Roy Amodeo) writes:
|> 
|> >One solution to this is to use a stack of errnos and errparms instead of
|> >single global variables. It also helps to have a user definable error
|> 
|> (in C, macros would reduce this), we were impressed with how well it
|> worked.  Whenever an error occurred, you'd get a message something
|> like
|> 

I also worked (in fortran) on a large physical design (CAD) program that
used a similar process, but only had error numbers.  We even went so
far as to have a coding scheme for the numbers, and a DB of text for
each number that could optionally be printed.  Made updates to the
text easier.

error number scheme was of the form "SMMMMEE" where S=severity (0-9),
M=module number ( each subroutine had a unique number assigned), and
EE was the error number with in the routine. 

This can add overhead, etc. BUT we also had a fortran macro processor
which also aids portability, etc. This WAS a large system with over
250K LOC, and about 1000 routines broken into about 10 individual
programs, and library routines (like error lookup, etc.

The Key is discipline, and making this type of decision during the
planning and design stage.

Any one recognize the system??

scott