Graceful failures

[Samuel Walters]

On Mon, 29 Dec 2003 14:14:43 -0800, Jacob H wrote:
> I'm somewhat reluctant to write a bunch of code for pretty windows that
> pop up with some message to the effect of, "internal error, game
> exiting." My main reservation here is it doesn't seem it can be done
> cross platform, and since my game is in a graphical console there's no
> place for stdout to write. However, if this is the best way to go about
> error handling, I'm willing to write the code. And I would appreciate
> advice about how to handle the cross platform problem. :)

I can't speak for any "canonical" way of doing things, but I do have some
thoughts on the matter from my experience in customer service and some
computer tutoring I used to do.  Maybe they can be of some use to you. 
Forgive me as I ramble for a minute, but I haven't spent time collecting
these thoughts.

Most computer users react to error messages with fear and panic.  They
feel like the computer is telling that *they* have done something wrong.
This misconception is compounded by the generally unintelligible error
messages thrown by most programs.  Computers have a way of making even
some of the most intelligent people feel stupid.

The second most common type of user understands that they didn't
necessarily do anything wrong, and just wishes the program would work.
They might thumb through the manual to see if it has anything on the
matter.  If they are given an obvious way to find a solution to the
problem, they will take it, but they generally won't work that hard.

The rest of us will dig in and try to solve the problem.  This could be
anything from using google, to posting on usenet, to reading a disassembly
of the core dump.


My "dream error dialog box" would do the following:

Tell the user in a very neutral and nontechnical manner that it has
encountered a problem and tell the user what it was trying to do when it
failed. 

for instance:
"""
Foo has encountered a problem.
Foo was unable to load the necessary images to continue. 
"""

The program should avoid words like "error."  You might consider having
the program keep a stack of descriptions of what it's trying to accomplish
at any given moment.  That allows you to differentiate between being
unable to open the configuration file with the intent of initially loading
the configuration and opening the configuration file with the intent of
reverting to original settings.

Next, tell the user whether or not they can continue and what some of the
consequences of continuing might be.

The error dialog box should allow the user the option of viewing technical
details, but should clearly label them as technical details.

If possible, the user should be presented with possible courses of action
to correct the problem.

Finally, I really, really wish that users were presented with the option
of being automagically taken to the technical support website where
they're allowed to see and discuss with others how to solve their
particular problem.  This is where I get a little bit hazy in my ideas.  I
envision a website/forum where a user can read and discuss possible
solutions to their problem *and* similar problems.  The proper web page
could be located from the stack trace.  If they're the first one to
encounter that particular stack trace, then tell them that they're the
first, politely ask them to describe the problem (even if the
description's useless to you, it makes the user feel included) and tell
them that your development staff has been notified and will be making
contact with them soon.  Offer to keep them updated via email when other
people post about having the same problem.

This type of system could be very useful to your development team and tech
support staff by allowing you to identify, track and fix the real life errors
that your users are encountering.

anyways...

HTH

Sam Walters

P.S.

If you haven't already, look at the Interface Hall of Shame to see what
*not* to do:
http://digilander.libero.it/chiediloapippo/Engineering/iarchitect/shame.htm