Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!rex!uflorida!travis!brad
From: brad@SSD.CSD.HARRIS.COM (Brad Appleton)
Newsgroups: comp.lang.c
Subject: Re: Managing error strings in C
Message-ID: <2114@travis.csd.harris.com>
Date: 22 Jan 91 16:08:40 GMT
References: <620@necssd.NEC.COM> <1991Jan19.163652.9203@hemel.bull.co.uk> <1991Jan22.021205.29632@dirtydog.ima.isc.com>
Sender: news@travis.csd.harris.com
Organization: Harris Computers Systems Division, Fort Lauderdale,FL
Lines: 40

Just wanted to add my $.02 ...

So far, All Ive seen on this thread talks only  about associating text, and a
unique number to an error as in:

  { EFOO, "unable to foo" },
          .
          .
          .

The stuff on parameter expansion/substitution in the format string is
interesting, however I believe one more thing should be included as part
of the "error" object - namely a severity (or level), as in:


  { EFOO, WARNING, "unable to foo" },
          .
          .
          .

The most common severity types are:
   1) Diagnostic (information messages only)
   2) Warnings
   3) Non-Fatal Errors
   4) Fatal Errors

I have also seen more "severity" levels used by adding an element of
user control to Warnings and Non-fatal errors such as, conditionally prompting
to continue or forcing termination after warnings and/or non-fatal errors
(such behavior may have been specified on the command-line and/or in an 
environment variable).

I think it is important to have some sense of severity associated with the
error in addition to its text and its id! As to the kind and number of 
severities or levels, that by itself is a worthy topic for discussion!

______________________ "And miles to go before I sleep." ______________________
 Brad Appleton           brad@ssd.csd.harris.com       Harris Computer Systems
                             uunet!hcx1!brad           Fort Lauderdale, FL USA
~~~~~~~~~~~~~~~~~~~~ Disclaimer: I said it, not my company! ~~~~~~~~~~~~~~~~~~~