Boost logo

Boost :

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.


> 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


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