From: williamkempf_at_[hidden]
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
will
> > always be re-thrown, but this does not have to be the case and
indeed a
> > library implementor cannot make that guarantee:
>
> No, I don't assume anything like this. Not re-throwing in catch
(...) will
> 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
special
> exception class that is always re-thrown at the end of the catch
(...)
> clause.
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
to be
> > robust the user must guarantee that something like the above
never occurs.
> > If any libraries are being used for which the source is not
available,
> this
> > isn't possible (unless you have complete trust in the library
vendor, I
> > suppose, but have fun tracking down _that_ kind of bug!).
>
> Have fun tracking the other kind of bug where the library you're
using is
> not exception safe (basic guarantee.) I don't see a problem here.
Either the
> 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
future.
Bill Kempf