From: Hendrik Schober (boost_at_[hidden])
Date: 2002-06-18 10:51:05
> When the OS exception is translated to a VCL exception, all stack
> information is lost (for the common example, all you get is the helpful
> message "Access Violation" -- gee, thanx, Borland! ;) ). What you describe
> above would work (i.e., get the full stack) only if your macros were used in
> the function that caused the OS exception and every function in-between that
> and the final catch.
In my logging/exception/assertion framework, when
used in a VCL environment, I do what Ted does and
for an AV get the file name and line number of the
stack trace macros nearest to the point the AV
occured. When used with VC, I don't touch SEH's at
all, since I like to have the debugger's stack dump.
(I meant to implement the other model for release
builds, but the pressure for it wasn't bad enough
to let it ever get at the top of my list. <g>)
> 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.
> There's no question that OS exceptions can be translated to C++ exceptions.
> I was just pointing out that traceable exceptions can't keep track of the
> stack until after the translation is made.
Again, look at www.HSchober.de/code/SEHTest.cpp.
It's easy to throw a tracable exception in this
> So, it comes back down to intrusiveness: I am writing some library. Do I
> include traceable exception macros in every function? Or maybe just every
> non-"trivial" function? [...]
I got used to the habit of putting them into
"top level functions" of every module/package/
subsystem/<however you call it>. That is, I put
them into those functions that are called from
If I have trouble finding an error in some code,
I tend to add more of them. <g> In old code,
there's usually quite a lot of them.
Also, I have a set of macros that disappear in
release mode, to be used in time critical code.
> What about exception-neutrality? If I call user code (either explicitly
> through a callback, or implicitly through a template parameter), and my
> function is supposed to be exception-neutral, how would I keep track of the
> stack? The only way I can see to make this work is to force *everyone* to
> use traceable exceptions...
Of course, the "intrusive model" isn't perfect.
But is did proof to be helpful for us during the
last five years.
After all, I _do_ look a lot at the stack dumps
in logfiles in order to find out what happened if
I lost my (usually always set) breakpoint at the
I lost my exception base class. I _was_ able to
find out about problems that weren't reproducable
here by only looking at the logfiles which were
created at the user's site. If this user is on the
other side of the planet (and is willing and able
to cooperate), that _is_ a very cheap way to do
> [...] 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?
> 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.
> 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
> I doubt it; even though I'm for the non-intrusive solution, I'll freely
> admit it's *much* more complicated! :) And will take many Boosters a good
> amount of time to get right.
> But I'd rather invest the time, and have a good, well-established,
> non-intrusive solution; even if it does take longer to write.
If it's provided as a library for everyone to use,
the effort it takes to develop it isn't that important
anymore (except for those who do the work <g>), since
it pays off everyone.
Ted might have though about him adding it to his project.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk