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

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

> > 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.
>
But what programmer effort do we need to be talking about?  Are we, or
should we be, restricting this to ONLY that required to use it, or both that
required to use it and that required to implement and validate it?  Relating
to this is the question of the potential usable life of the code.  If the
non-intrusive approach is  so tightly tied to the platform, how long will it
be before it has to be done again?  The core traceable exceptions could well
be written entirely portably in standard C++, and thus could continue to be
used as long as C++ exists as a language.

> > 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.
>
Fair enough.  Then, something I have had bouncing around in the back of my
mind (and will probably do so until I figure out how to do it), may be worth
discussing.  I was thinking about the possibilities of having this
controlled to some extent at run time, perhaps using a standard bitset to
manage flags governing which modules and which kinds of exceptions are
traced; perhaps in conjunction with a traits class and/or policy class that
sets particular options.  I haven't even begun the analysis required to
figure out what is required for this, or how it works, but I have read
enough of "Modern C++ Design" to be aware of the potential.

> >
> > 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?
>
Yes you could.  And, it might.

Something I was considering was to add a vector of pairs of strings
(label+value), and alter the output operator to output the contents of that
vector also, if there is anything in it.  Then, in any specialization of the
template, the constructor body would no longer be empty: instead it would
add suitable pairs of strings to this new vector (or maybe just use a vector
of strings so each string has what would have been in the pair of strings),
labelling and storing any additional data that may be in the exception to be
converted into a traceable exception.  Such a use of specialization, and an
extra data member in the base class specifically to facilitate such
specializations, would reduce or eliminate the need for further derivation.

> 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.
>
Yes, this occured to me as I considered additional special exceptions that
could be constructed for particular blocks of code designed a) to take
advantage of this idea of being able to store extra information from the
translated exceptions, and b) to capture in a convenient form additional
information, either from the code block itself, or some function that
collects the additional information Steve was talking about.

This would allow us the flexibility to gather as much, or as little,
additional information as we wish (especially in the case where an assertion
fails: we could collect any information we wish, package it in a custom
exception, and pass that exception to one of the template functions that
take any exception and throw a traceable exception, which in turn will allow
us to construct the trace before the program dies (or the exception is
handled at some point in the try sequence).

> > > 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.
>
OK, but like I said, it may well be early next week by the time it appears.

Cheers,

Ted