From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-16 12:28:54
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "bill_kempf" <williamkempf_at_h...>
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > A programmer that wants to catch the cancellation exception may
> > have good
> > > reasons to do so. In particular, letting an exception escape
> > > destructor during stack unwinding terminates the process, no
> > questions
> > > asked. ;-)
> > That's not a reason to catch the request, it's a reason to
> > requests. A cancellation "exception" can be uncatchable and
> > safe in cases such as this.
> So, code that currently has
> // ...
> // eat exceptions, we're in a destructor
> will need to be fixed to disable cancellation as well.
Only if it makes calls to any "cancellation points".
> > > Making this exception non-catchable by catch(...) may also
> > correct
> > > code (in the sense that it may silently become exception
> > Care to explain in detail?
> // ...
> Not very good style but correct and working.
Not conforming to the current Boost.Threads interface, however.
There's no access to lock()/unlock() methods on a mutex.
I do see the point, however. RAII isn't used universally to insure
proper resource cleanup is performed. Good point.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk