Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!ssc-vax!lee
From: lee@ssc-vax.UUCP (Lee Carver)
Newsgroups: comp.unix.wizards
Subject: Re: friendly messages
Summary: How about "Let's talk about it"
Message-ID: <1238@ssc-bee.ssc-vax.UUCP>
Date: 6 Mar 89 17:35:47 GMT
References: <435@laic.UUCP> <955@auspex.UUCP> <9218@bloom-beacon.MIT.EDU> <1369@dsacg3.UUCP>
Distribution: usa
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 30

In article <1369@dsacg3.UUCP>, vfm6066@dsacg3.UUCP (John A. Ebersold) writes:
> In article <1089@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
> >>The consensus seems to be (correct me if I'm wrong.. :-) that error
> >>messages should say just enough to please the user and no more.
> >
> >Yes.  However, one gets the impression that some programmers have a
> >quite bogus idea of how much this actually is - often bogusly small.
> 
> Yes, like printing errno, instead of the error message.
> 

Actually, the problem is that there is NO right level of detail.
The slickest approach I've seen is to let the user decide how much
detail to look at.  No surpisingly, this approach is well based in
cognitive psychology.

A recent CACM paper (K Efe, "A proposed solution to the problem of
levels in error-message generation", CACM, vol 30, no 11, Nov 1987,
pg 948) provides a very simple implementation.  It allows the user
to review the failed execution, and uncover the problem.  It also
starts with a good discussion of why a single error message is
inadequate.  Basically, it put the programmer in the position of
arrogantly "knowing" what the user wants.

For those without the paper, it is basically a tarceback stack in
user sensible terminalogy.  You don't have to implement all the
"what next" capability in his paper to have a useful error system.

Lee Carver
Boeing Aerospace