[boost] Re: Re: improved assertions?

From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2002-06-14 12:32:48

> But now consider: on the Win32 platform, in the case of an access
violation
> (the most common "fatal" programming error), an OS exception (not a C++
> exception) is raised.  Traceable exceptions can only trace the stack down
to
> the point where the OS exception is translated to a C++ exception, not at
> the actual point of error.  If you're a Borland user, the first catch()
for
> a VCL object will make this translation; if you don't use the VCL, this
> translation is never made.  I'm not sure how MSVC handles this.
>
But this is easy to accomodate.  First, check back to Schobi's site in a
little while, as I just sent him an updated version of my prototype.  In it,
you will see I have added specializations of my template class for both the
standard C++ exceptions and VCL exception.  Then, I added a number of macros
and utility functions (whose usage requires creation of a couple string
variables which ideally ought to be static).  I think these macros and
utility functions greatly ease the use of this library.

BTW: in my traceable exception prototype library, there is some stuff that
is specific for Borland's VCL, but that is easily either removed, or
surrounded by conditional defines, so that it should remain fairly easy to
use with other tools and on other platforms.

Now, whether you're using the VCL or not, you can use structured exception
handling, as described in the win32 programmer's reference.  To use them in
conjunction with my traceable exceptions, there are a number of obvious
options.  One is to create a try/except equivalent of my try/catch block
macros, and nest their use INSIDE a pair of my try/catch macros.  The, with
the utility functions needed for structured exception handling, the OS
exceptions can be converted into the appropriate traceable exception.  In
MSVC, you'd do the same, except take note that MS extension for except
blocks uses a slightly different keyword than does Borland; I swear they
must do this just to make my code even uglier! ;-)  But the win32
programmer's reference has some nice documentation for structured exception
handling, which probably ought to be examined before trying this.  An
alternative is to write a custom signal handler that converts hardware or OS
exceptions into traceable exceptions, but not having created or used my own
signal handlers, that is at present a little beyond me.

> Also, I did not want stack tracing added to other "non-fatal" exceptions.
I
> do use exceptions to indicate errors for operations that can be retried,
and
> in one case I even use an exception as an end-of-input designator for a
file
> parser (whose design is patterned after Iterators in the Python language).
> Adding stack traces for these exceptions is just adding overhead.
>
But I have designed my library so that all my traceable exceptions are
rethrown and all others are converted into one of my traceable exceptions
which is then thrown.  I did this specifically so that there remains the
option of handling non-fatal exceptions as represented by one of my
traceable exceptions.  Of course, there is nothing to prevent one from
adding another try/catch block in between my macros, which will allow
non-fatal exceptions to be handled without a traceable exception even being
generated.  The use of the two is not mutually exclusive.

> I think the biggest issue, though, is intrusive vs. non-intrusive design.
>
I am not so sure.  I think the issue here will depend on the skills of the
programmer and how long it will take to do the one or the other.  I'd bet
that even with my current project, it would take me longer to figure out how
to implement a non-intrusive design, and then implement and prove it
correct, than it would to add my string variables and macros to each
function in even a medium sized project.  For a more skilled programmer, the
opposite may well be true.

Cheers,

Ted