Re: [boost] Re: Re: improved assertions?

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-06-14 17:55:42

----- Original Message -----
From: "Ted Byers" <r.ted.byers_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Friday, June 14, 2002 6:47 PM
Subject: [boost] Re: Re: improved assertions?

> >
> > 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.
>
I meant with the minimum programmer intervention.
The non-intrusive approach offers the maximum possibility on this item.

>
> 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?
>
This desicion would depend on the runtime/compile time overhead introduced
by the framework. If either of these turns out to be too much, I'd like to
turn it off for those modules I don't care to track.
It could happen that a given library throws an exception and I can't trace
it because I've turned tracing off; but at a particular time in the
development cycle, I might just don't care about that.
For example, I deal daily with about a dozen or more DLLs of my own, but I
only use debug and diagnostic information on one or two at a given time.
These increases runtime a lot. If something goes wrong in one of those DLLs,
I schedule a revision for later and keep focusing on what I'm doing now.

>
> 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.
>
I see. I looked at your code. Couldn't you derive from the captured
exception? Would this help?

BTW, the oportunity to collect more than the execution frame seems to me
like the most valuable feature which cannot be offered by the automatic
stack tracing approach. This could even mean that both could co-exist and
collaborate.

> 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.
>
You're absolutely right!  I didn't meant to say that the requirement list
was already settled. Of course we need to discuss this list first.

> > 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.
>
>
I think it would be more usuable if you post it as complete cpp files we can
just pick, compile and watch running.

Even if this sort of thing never gets submitted or accepted, it seems
beneficial to me to explore it; it seems that there's general need for this,
but also that it isn't clear which way to go.

Cheers,

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com