Boost logo

Boost :

From: Hendrik Schober (boost_at_[hidden])
Date: 2002-06-18 10:51:05

<scleary_at_[hidden]> wrote:
> [...]
> 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
  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
  other modules.
  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
  remote debugging.

> [...] 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
  that code.

> [...]
> 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.

> -Steve


Boost list run by bdawes at, gregod at, cpdaniel at, john at