[boost] Re: Re: improved assertions?

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

<scleary_at_[hidden]> wrote:
> [...]
> I toyed with traceable exceptions back before I decided to go the other way.
> Like you, I was only interested in a stack trace when something goes
> *really* bad -- like my program is about to fatally exit.

  But what is "really" bad when you do event based 
  programming? Like, for an example, if printing 
  fails fatally, you end up in the message loop 
  (where for Windows you _have_ to catch every 
  exceptions, since you're not allowed to let any 
  exception leak into the OS). So printing failed. 
  But should I then terminate the application? Why 
  not let the user try to save the document? 
  Of course, that might fail, too, since the app
  is probably in a state where nothing works anymore. 
  But then, it might succeed. 
  (If you're writing applications for dummies (as we 
  mostly do), having users that don't save for a 
  long time is pretty common.) 
  Bottom line: In non-critical, interactive, event-
  driven applications, if one event fails, let the 
  users decide whether they want to restart the app 
  or go ahead and try another event. 

  Once you do that, what's a fatal error? 

> But now consider: on the Win32 platform, in the case of an access violation
> (the most common "fatal" programming error), an OS exception (not a C++
> exception) is raised.  Traceable exceptions can only trace the stack down to
> the point where the OS exception is translated to a C++ exception, not at
> the actual point of error.  

  There's a WinAPI function that you can use to 
  install a handler for those events. 

>                             If you're a Borland user, the first catch() for
> a VCL object will make this translation; if you don't use the VCL, this
> translation is never made.  I'm not sure how MSVC handles this.

  See www.HSchober.de/code/SEHTest.cpp. 

> Also, I did not want stack tracing added to other "non-fatal" exceptions. [...]

  If this performance is really a concern to you (which 
  seems odd, since exceptions can have a lot of overhead
  by themselves), then a non-traced exception would be 
  the way to go. 

> I think the biggest issue, though, is intrusive vs. non-intrusive design.

  I like the previously mentioned idea, that these do not 
  exclude each other and can co-exist. 

> -Steve

  Schobi