From: Hendrik Schober (boost_at_[hidden])
Date: 2002-06-18 10:15:53
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk