[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


At 10:19 28/06/93 -0400, Jeff Morrill wrote :
>I just placed the file menu-debugger.lisp in the clim library
>under clim-2.  It is a simple but useful utility that exposes
>a menu of restart actions when an error is signalled.  It is
>useful as a firewall to keep naive users out of the "real"
>debugger when unexpected errors are encountered.

Is there a general consensus on how to deal with errors for a "naive user
delivered" application?  My impression is that the user should not be
concerned with choices to do because of some programmer's errors.

I have been thinking about that lately and have a few ideas for which I'd
like comments from the experienced lispers out there.

The idea would be to put a "catch" (something like ignore-errors or a
handler-case on "error" or "condition") at the highest level possible
(around the top-level loop?).  Then run some code to produce as complete a
report of the error as possible that would be written to a file, put up a
dialog to the user saying something like "This action could not be
completed for unknown circumstances.  Please contact the developer for
fixing this problem." and then restart the toplevel loop.

When the user contacts the developer (or when maintenance occurs), he could
have a trace of the problem that occured and have (maybe) enough material
to solve it (or better handle it thru specialized handler-cases).  This
would have the advantage that the user can still use the other
functionalites of the system (by helping him know what parts of the system
have problem... some kind of graceful degradation.)

This, of course, would not prevent the good developer from writing error
free code and correctly targeted handler-cases...   ;-)

Any ideas, thoughts?


Keunen Vincent
R&D, Software Engineer
tel: +32 41 407282
fax: +32 41 481170