Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-16 18:43:27


--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
>
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
>
> > > 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;
> >
> > Such code isn't exception safe any way. I don't find that to be
a
> > compelling argument.
> >
> > In other words, "finalizeUpdate" needs to be either in a RAII
> > mechanism or placed in the catch(...).
>
> Uh, why do you say that?

Ooops, sorry, my mistake. (Man, it's been a bad day.) I should have
thought about that one a bit more. Not sure I've ever seen code
structured this way, but it's a valid point.

So, all this discussion leads us to:

1) Use deferred cancellation (and allow the user to turn cancellation
off).
2) Use a C++ exception for cancellation.
3) Allow the user to catch the exception.
4) Allow the user to "eat" the exception.
5) Make the cancellation "flag" a sticky flag, so if the user "eats"
the exception it will eventually be re-thrown when they call another
cancellation point.
6) Ensure cancellation points don't throw when uncaught_exception()
returns true.
7) Document that in general one should always rethrow a caught
cancelation exception.

Bill Kempf


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