Xref: utzoo comp.software-eng:4423 comp.lang.c:33646 Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!rutgers!apple!netcom!teda!ditka!mcdchg!tellab5!balr!clrcom!rmartin From: rmartin@clear.com (Bob Martin) Newsgroups: comp.software-eng,comp.lang.c Subject: Re: error handling techniques? Message-ID: <1990Nov3.153643.26368@clear.com> Date: 3 Nov 90 15:36:43 GMT References: <1990Nov2.205831.23696@elroy.jpl.nasa.gov> Organization: Clear Communications, Inc. Lines: 40 In article <1990Nov2.205831.23696@elroy.jpl.nasa.gov> alan@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 Alan: In a large software system the number of places where the code can detect errors can range into the tens of thousands. Every call to malloc should be checked, every IO operation, every place where something can go wrong should be checked... This leads to an enormous amount of error checking and error messages. What I have done in the past to cope with this is to create an ErrorLog function which will write single line error messages into an error log file. The messages consist of the time, process id, and three numbers. mod,loc(param). is a unique number which identifies the module in which the error occured. (by module I mean .c file.) is a number unique to that modules which identifies the specific call the the ErrorLog function. Thus if a module can detect 20 errors, it will do so with 20 separate numbers. Errors of similar types should _not_ use the same ! is a piece of useful information (if any) which can be logged with the error. For example, when a malloc returns NULL, I usually put the size that I was attempting to malloc in the . errno would be useful in when appropriate.... Every hour I close the current error log file and open a new one. At the end of the day I compile then into a summary and eyeball them to see if anything horrible went wrong. Software can be written to automatically scan these logs to see if there are critical errors. Hope this helps. I welcome discussion. ---------------------------------------------------------------------- R. Martin rmartin@clear.com uunet!clrcom!rmartin ----------------------------------------------------------------------