Date: 2001-08-23 10:14:18
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "Scott McCaskill" <scott_at_m...>
> > You're assuming that use of catch(...) implies that the exception
> > always be re-thrown, but this does not have to be the case and
> > library implementor cannot make that guarantee:
> No, I don't assume anything like this. Not re-throwing in catch
> ignore the cancelation request. This is a feature.
That's a bug. If I ask a thread to cancel it darn well better do
so. Being able to catch is fine, being able to stop the cancellation
is not. However, there's tricks that can be employed to insure the
exception is rethrown regardless of what the user codes for his catch
> If you don't like the feature, you need core language support for a
> exception class that is always re-thrown at the end of the catch
This can be done with out language support. Alexander (I believe)
already posted code to this list that accomplishes this.
> > So, thread cancellation is implemented this way, in order for it
> > robust the user must guarantee that something like the above
> > If any libraries are being used for which the source is not
> > isn't possible (unless you have complete trust in the library
> > suppose, but have fun tracking down _that_ kind of bug!).
> Have fun tracking the other kind of bug where the library you're
> not exception safe (basic guarantee.) I don't see a problem here.
> library you're using works or it doesn't.
Using an exception is going to be problematic with legacy code even
if you can shore up all the reasonable holes. That makes me nervous,
but this will likely be the solution chosen by Boost.Threads in the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk