|
Boost : |
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2007-09-15 12:57:16
On 9/15/07, Howard Hinnant <hinnant_at_[hidden]> wrote:
> On Sep 13, 2007, at 2:23 PM, Howard Hinnant wrote:
>
> I promised to explain myself after a day or two and that time has
> come. Thanks much to everyone who has responded.
>
> The application is thread cancellation. One might want to call this
> thread interruption or whatever. Thread interruption (I shall use the
> term interruption as opposed to cancellation for really no good
> reason) is essentially an exception. The stack gets unwound,
> executing "landing pads" on the way up. Those "landing pads" in C++
> are destructors and catch clauses.
>
> If ~A() is really not nothrow (even though it appears to be), then
> std::vector is really not going to work very well in an exceptional
> condition (i.e. it will leak A's). I.e. I have grave concerns over
> sticky_exception myself, even if its only application is thread
> interruption.
>
The other 'example' of sticky exceptions, that we all accept as valid,
is throwing inside a constructor - you can't catch a base class
constructor throw and handle it in the derived class' constructor.
I bring that up as a somewhat related example of 'sticky' exceptions.
Not that I think the thread case should necessarily follow the same
idea.
Tony
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk