C/C++ style Crashes?

[Steve Horne]

On Fri, 12 Jan 2007 09:48:50 +0100, Alexander Panek
<a.panek at brainsware.org> wrote:

>> An important point is that this doesn't solve this problem either. Ok,
>> you get an exception instead of some "undefined behaviour", which is
>> somehow better when debugging, but:
>> 
>> It just doen't solve the problem that you have a bug in your program in
>> the first place. Reread that sentence.
>
>Exceptions can be handled at runtime, still. try (to) catch it and there 
>you go. :)

There is a big difference between using exceptions to handle user
errors, machine limits and the like compared with handling program
bugs.

Put it this way - if your code generates exceptions due to bugs, how
exactly can you trust the exception handlers to do any better? If your
program is in an unknown illegal state because of an unknown bug, how
can your exception handler convert that back to a legal state?

Exceptions are meant to handle exceptional cases cleanly - hence the
name. We tend to think of exceptions as errors, but that isn't
necessarily the case, and besides, the meaning of error in this
context does not include bugs in the code.

Trying to hide bugs behind a catch-all exception handler tends to mean
the application stays in an illegal, unstable state that leads to more
errors. Instead of exiting at the first sign of trouble with a minimum
of data loss, the effects of that error can snowball - files get
corrupted with bad data etc etc. Things that seem minor along these
lines can actually be the worst cases - an accumulation of minor
corruptions can go unnoticed until the point where all existing
backups are corrupted, and suddenly the "clever" hiding of bugs has
led to bad publicity and paying out for damages.

Exceptions are only better than "undefined behaviour" when debugging
since you get clues to how the error arose that allow you to diagnose
and fix the bug more easily (providing it is the kind of error that
results in an exception). For instance, the debugger will stop on
unhandled exceptions, and show you where the exception throw happened,
what was on the call stack, etc.

Even then, so much can happen between the initial error and the point
where it is detected and an exception thrown that you still have a
serious detective job to do. And if you have a bug-hiding catch-all
exception handler, there just means that even more will have happened
between the initial error and its detection and the detective job will
be many times more difficult.

Catch-all exception handlers can be useful for generating diagnostic
data, but using them to hide bugs is bad programming.

-- 
Remove 'wants' and 'nospam' from e-mail.