Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: friendly messages
Message-ID: <1337@auspex.UUCP>
Date: 30 Mar 89 23:27:57 GMT
References: <435@laic.UUCP> <955@auspex.UUCP> <9218@bloom-beacon.MIT.EDU> <9780@smoke.BRL.MIL> <3314@ficc.uu.net> <1411@moscom.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 29


 >A nice quick 90% solution is a printf-like function that writes to stderr,
 >prepends the program name to the message, and can append the system error
 >message.  Something like:
 >	if (open(fname, O_RDRW, 0) == -1)
 >		errmsg("Cannot open \"%s\" for read/write -- ", fname);
 >would output:
 >	prog: Cannot open "somefile" for read/write -- Read-only file system

CAREful - you may want to call this function for errors that *don't*
cause "errno" to be set.  You might want to have some way to indicate
whether it should use "errno" or not - or, perhaps, just use the
(dp)ANSI C routine "strerror", which takes an "errno" as argument and
returns a pointer to the appropriate error message string, and just
stick "%s"es into the message string and calls to "strerror" into the
argument list.  (If your implementation doesn't have "strerror", it's
probably a 5-minute job to whip one up, at least under UNIX.)

 >This makes it fairly painless for the programmer to come up with an
 >informative message without worrying about the little details.  Trying
 >to use perror to get a nice message is too much work, which is probably
 >why it isn't used as often as it should be.

Yes, but unfortunately burying the call to "perror" in "errmsg" has its
own problems.  Note also that there are places other than "errno" where
errors are reported (by other packages, such as TLI, ONC RPC, database
libraries, etc.), often with their own families of error codes and messages,
so you may end up having to stick calls to the "return error message"
code in *anyway* in some cases....