Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: friendly messages
Message-ID: <9781@smoke.BRL.MIL>
Date: 3 Mar 89 12:05:29 GMT
References: <435@laic.UUCP> <955@auspex.UUCP> <9218@bloom-beacon.MIT.EDU> <5734@bsu-cs.UUCP> <90507@sun.uucp> <259@celerity.UUCP> <4970@xenna.Encore.COM> <1069@auspex.UUCP> <2849@osiris.UUCP> <1089@auspex.UUCP> <1369@dsacg3.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <1369@dsacg3.UUCP> vfm6066@dsacg3.UUCP (John A. Ebersold) writes:
-How many times has anyone heard (or said) something like.  "I'm not checking
-the return value becuase I can't do anything about it anyway."
-To me, this is not true.  You can always print a message that says:
-Horrible error in program foo, function bar, the function bletch returned a
--1 on about line x.
-I'd rather have this than a mysterious failure.

I agree with you in general; however, there's one common case where the
best solution seems to be to ignore the failure:  when an attempt to
output an error message (to stderr, usually) fails.  What are you going
to do, try to print yet another error message?

The "assert" macro defined by "#include <assert.h>" is very handy for
handling program logic bugs, in many cases.  Sometimes it is important
to try to recover from an error and resume normal operation, rather
than terminating the process.