[boost] Re: Re: improved assertions?

From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2002-06-14 16:47:53

>
> These are my requirements in order of priority:
>
> 1) I need to access the context information on the point of the exception
> from the point of the handler.
> 2) I need to be able to hide the recorded and collected information for
> release builds
> 3) I need to see the as much as possible of the execution path that led to
> the point of exception.
> 4) I want to do this as automatically as possible.
> 5) I'd like to be able to select which exceptions do I want to track and
on
> which parts of the application.
> 6) I'd like to be able to customize the information recorded, for example,
I
> might need to see the expression that violated an assertion.
> [...]
> The question is: how does Ted's and Steve's schemes fit these
requirements?
>
I'll let Steve comment on how well he can accomodate these.  But it seems to
me that traceable exceptions can mostly accomodate them, depending on how
they're used.
1 is already provided.
2 is trivial to add (just need to make the macros conditionally defined
based on whether or not we're building a release or debug build.
3 is provided for all of the code you have written yourself (and any library
that also uses the same traceable exception library).
It isn't quite clear to me what you mean by your item 4.  It seems to me
that traceable exceptions are prety automatic, once the macros are in place
where needed.  But Steve's seems more automatic, in the sense that it isn't
intrusive.
5 and 6 might take more work, for the user, especially if these choices
change from day to day.  To make them much more useful and easy to use, I'd
be interested in exploring whether or not my traceable exceptions can be
enhanced by providing support for policy classes (I've heard much about
these, but have not yet figured out how to implement and use them: and I
ain't too proud to ask for help).  But is that worth doing.  After all,
surely, when a problem arises, we want as much information as possible from
wherever the problem arose.  What, then, do we gain by turning off this
capability in one part of the code and leaving it one in another?

For item 6, I have already been wresting with how to provide greater
flexibility in the information ( as I mentioned n passing in my last reply
to Steve), but I am not sure which way to go.  There may well be several
viable options to accomodate this with my traceable exceptions, but I
haven't worked them through yet.

BTW: I would take exception to the statement that "The question is: how does
Ted's and Steve's schemes fit these requirements?"  Surely the first
question OUGHT to be, is this set of requirements satisfactory?  Are there
others that need to be added?  One, certainly needs to be clarified.  Are
there any that need to be revised or removed enturely?  I am not sure.

> BTW: Ted, why don't you add to the site some examples so we can see how
does
> it look like when used.
>
OK, but it may be early next week by the time they appear.  Or I can post
some here if you like, as an example of several kinds of use isn't likely to
require more than a dozen or so lines of code.

Cheers,

Ted