Re: Re: any_function (callback) library

From: Jacob Hammeken (njacobh_at_[hidden])
Date: 2001-04-11 15:00:58

William Kempf wrote:
> In any event, the JIT debugger handles exceptions as easily as it
> does assertions, dropping you into the code at the point where the
> exception was thrown.  So I don't know what you're trying to say here.

Exceptions are used by many libraries for cases which may be perfectly
normal, such as 'file not found'. I think stopping the program for normal
cases makes debugging more time consuming because you may have to resume the
program just because something perfectly normal happened, which may be why
you can tell the (VC) debugger not to stop the program if an exception is
thrown.

On the other hand, if the program is about to call a zero pointer, it seems
to me that the author probably does not know what is going on, so you would
typically want the program to stop at the point where a platform specific
action ('crash') would otherwise have occurred, which is what an assertion
does (or at least all of the implementations I have used). An assertion
always stops the program if the expression is not valid, while an exception
may be caugth.

Let us say you are using the ScopeGuard template (by Andrei Alexandrescu) to
call a 'function' or 'any_function' (if that is possible, otherwise consider
a template which calls a 'function' in its destructor). If I remember
correctly, the destructor of the ScopeGuard template guarantees not to throw
by means of surrounding the call with a try{}catch(...) {}. If an exception
was thrown, you would never know about it unless the debugger stopped the
program, but stopping the program when an exception is thrown may, as
previously mentioned, not always be desirable for everyone, and you would
not know about it in release builds. By contrast, an assertion would always
catch this exceptionally bad use of pointers, in debug builds.

For release builds, testing whether a pointer is zero in the code may not
always be sufficient anyway; third party libraries could still cause illegal
operations.Or the compiler could be buggy (shiver!). I think the only way to
make sure you can at least try to do some cleanup and logging if something
bad happens is to use something the C++ language does not explicitly offer;
on Win32 that would be structured exception handling. Using that approach,
most or all of the bugs would hopefully be taken care of while debugging,
there would be no need for the extra comparison and the throw, and it would
probably be more safe as long as there is OS support for dealing with
hardware exceptions.

Jacob Hammeken