Re: first sight

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 
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".

> 
> > > Making this exception non-catchable by catch(...) may also 
break 
> > correct
> > > code (in the sense that it may silently become exception 
unsafe.)
> > 
> > Care to explain in detail?
> 
> systemWideMutex.lock();
> 
> try
> {
> // ...
> }
> catch(...)
> {
>     systemWideMutex.unlock();
>     throw;
> }
> 
> systemWideMutex.unlock();
> 
> 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.
 
Bill Kempf