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

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 www.HSchober.de/code/SEHTest.cpp. 
  It's easy to throw a tracable exception in this 
  case. 

> 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

  Schobi