Re: contracted exceptions

["Randy Brukardt" <randy@rrsoftware.com>]

"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. That compiler's facilities were used as the model
for error handling in Janus/Ada [although not the local variable dumps...too
much overhead])

                            Randy.