Boost logo

Boost :

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-16 17:38:26


--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- 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
> from a
> > > > destructor during stack unwinding terminates the process, no
> > > questions
> > > > asked. ;-)
> > >
> > > That's not a reason to catch the request, it's a reason to
> DISABLE
> > > requests. A cancellation "exception" can be uncatchable and
> still be
> > > safe in cases such as this.
> >
> > So, code that currently has
> >
> > try
> > {
> > // ...
> > }
> > catch(...)
> > {
> > // 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".

Such as thread-shared data access, mutex locking?

Also, with respect to auto_rethrow_exception:

 scoped_lock lock( systemWideMutex );

 beginUpdates(); // modify something; nothrow

 try
 {
    // ... plug-in oper ;-) strong
 }
 // ...
 catch(...)
 {
    // ...
 }

 finalizeUpdates(); // final modifications; nothrow

 return;

regards,
alexander.


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