Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-19 06:25:12


----- Original Message -----
From: "Jesse Jones" <jesjones_at_[hidden]>
To: "David Abrahams" <abrahams_at_[hidden]>; <boost_at_[hidden]>
Sent: Wednesday, April 18, 2001 7:03 PM
Subject: Re: [boost] Re: Boost.Assertion

> At 7:42 AM -0400 4/18/01, David Abrahams wrote:
> >----- Original Message -----
> >From: "Jesse Jones" <jesjones_at_[hidden]>
> >
> >> I thought std::uncaught_exception() was pretty much worthless, but I
> >> confess I don't know all the details (and the archives don't have
> >> much to say). Can we really use this inside a dtor to see if the
> >> stack is being unwound because of an exception?
> >
> >Yes (if the compiler conforms). The problem with uncaught_exception() is
> >that it won't detect the case where you're inside a catch block which is
> >going to rethrow the exception:
> >
> >try {
> >}
> >catch(...) {
> > // cleanup actions...
> > // <=== uncaught_exception() is false here
> > // more cleanup actions...
> > throw;
> >}
> >
> >This condition is almost the moral equivalent of being inside a
destructor
> >during stack unwinding: the supposedly neccessary "more cleanup actions"
> >won't be executed if you rethrow here. Also, the active exception is
lost.
>
> Hmm, well that's still useful. For example, it makes file classes a
> bit easier to write. Instead of using a close() method you can do the
> close in the dtor. If an error is returned you can throw if
> uncaught_exception() returns true. Too bad CodeWarrior doesn't
> support it...

Careful... you'd better be sure you didn't create your file object inside a
catch block. I guess the chances are low, but all the same, it's a risk.

Do you see now? If you use uncaught_exception to tell you whether it's
"safe" to throw from a destructor, you have to either:
1. Prohibit construction of the class inside catch blocks
2. Limit your definition of "safe" to "won't cause immediate termination,
but might skip unwinding actions and/or lose exception information".

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk