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
> 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
> > [...]
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk