Error routines
Posted in 1994
Folks, What with all the error routines floating around, with similar error handling but slightly different needs, I thought that we should probably come up with THE ERROR ROUTINE. Or at least list all of the things that are important to us (me). Here's my stab at it. Error routine should: a) give the user a clear error message along with some option of what do next. If it is a fatal error the program should exit, otherwise the routine should allow for recovery. b) provide for clean up of damaged data. (e.g. - for systems which "do their own locking" - delete the locks). c) develop a second error message for the developer which identifies: - source module - including version - line of code - datetime - user - node - what the error is d) get this second error message to the proper developer (depending on the system either quickly or whenever). To us this means the last person to modify the code. I am always tempted to go about specifying how to do each of these things, but I'll wait until I get some feedback from y'all. cheers j. _____________________________________________________________________________ Jack Parker | Hewlett Packard, BSMC Boise, Idaho, USA| Please note change of email address. jparker@hpbs3645.boi.hp.com | <--------- (208) 396-5388 (W) (208) 384-1623 (H) | _____________________________________________________________________________ Any opinions expressed herein are my own and not those of my employers. _____________________________________________________________________________