Re: contracted exceptions

[Kilgallen@SpamCop.net (Larry Kilgallen)]

In article <f4cr8j$mb8$1@jacob-sparre.dk>, "Randy Brukardt" <randy@rrsoftware.com> writes:
> "Simon Wright" <simon.j.wright@mac.com> wrote in message
> news:m2k5ue8dhk.fsf@mac.com...
> ...
>> If our fielded application raises an unhandled exception it's going to
>> be the result of a design error or at least a design shortcoming. We
>> will log the exception traceback and stop all application processing;
>> the system is in an unstable state. The operator can then restart and
>> (if we are lucky) send us the fault log for debugging. If we're
>> unlucky they'll just complain about us to each other and our
>> reputation is shot.
>>
>> The operator has no access to or interest in a debugger.
> 
> And that's true for virtually all applications. [Aside: didn't we have this
> discussion a few months ago??] Only the original developer(s) care about why
> something failed; other users (the vast majority) only care that it failed.
> Even users of a compiler don't want an internal error to throw them into a
> debugger: what value could that have? (As for the original developer(s),
> they can only use a debugger if they can reproduce the actual error -- and
> the ability to do that is rare. It's actually better to have the partial
> information from a good logging mechanism, because at least some fraction of
> the time the error will be obvious and fixable. And the information doesn't
> have to be that partial; I recall that the error dump on the Pascal compiler
> we used in college actually dumped all of the local variables in its
> traceback on a failure.

There is a long tradition of a "core dump" on a failing program,
although these days it tends to be more structured.  The VMS dump
from an application can be examined back at the developer's shop
using the regular debugger interface -- for those cases where the
security policy of the user site allows export of such opaque data
to the developer.