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

From: scleary_at_[hidden]
Date: 2002-06-18 15:18:16

> From: Hendrik Schober [mailto:boost_at_[hidden]]
> > OTOH, you would have all stack information from the point 
> of translation
> > outward, and maybe that would be good enough...
> 
>   It proofed to be a help for debugging with Borland, 
>   since you can't get a stack trace otherwise. 

That's exactly what my stack tracing solution is for.

> > [...] With my current non-intrusive
> > solution, the stack tracing is not done unless it is an OS 
> exception.
> 
>   Is there anything preventing it from beeing used 
>   within the exception class' ctor? 

No.  It should be able to be done at any time.

> > [...]
> > We've been focusing on tracing the stack from the point an 
> exception was
> > thrown.  My solution traces the call stack; yours the "try" 
> stack -- but
> > they both focus on the *exception*.  Maybe this is wrong; 
> the original post
> > in this thread was about *assertions*. [...]
> 
>   As I've written elsewhere in this(?) thread, aborting 
>   in case of an error isn't an option for me, even if 
>   it is a serious ("fatal") error. So my assert macro 
>   throws an exception which can be caught. This exception 
>   will be traced as any other of my exceptions. 

"assertion" here could mean different things.  I didn't mean to abort, since
(in my products) the desired behavior is to throw an exception of a special
type that is only caught by the outermost try...catch of a thread, and thus
treated as a "fatal" error *after* the stack has been traced and then
unwound.

> > [...]
> > Intrusiveness begs the questions: you add it to your code.  
> Good.  Are you
> > going to add it to the Boost.SmartPtr library?  Are you 
> going to add it to
> > your own general-purpose library, that you plan to put on 
> your web page?
> > What about that commercial XML parser library your project 
> uses?  Where does
> > it stop?
> > 
> > A non-intrusive solution sidesteps this question, almost. ;)
> 
>   While that's true, I usually consider 3rd party code 
>   as a black box. I do not care what happens inside it 
>   as I expect the writers of that code to debug it. So 
>   I'm simply not interested in stack information about 
>   that code. 

But sometimes it can certainly help.  I had strange, intermittent (very
rare) problems with the VCL client sockets that ended up being a bug in the
VCL (fixed in BCB5) concerning re-entrantcy issues.  That was a couple years
ago, and I was writing my first asynchronous-based program, so I naturally
assumed the bug was somewhere in my code until I was able to show that it
was in the VCL (which was shown using stack traces).

No library is perfect. :)

>   Ted might have though about him adding it to his project. 

Yes, it's been hinted at a few times in various e-mails.  Let's say that the
stack tracing and tracable exceptions are both developed independently; then
there's no reason why Ted's macros couldn't be modified to trace the stack
and wrap that in a traceable exception.  The only problem I see is that it
would be difficult to avoid duplicate information.

        -Steve