Re: [boost] [RFC] sticky_exception

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-09-15 10:17:43

On Sep 13, 2007, at 2:23 PM, Howard Hinnant wrote:

> class sticky_exception
> {
>     bool owns_;
>     sticky_exception& operator=(const sticky_exception&);
> public:
>     sticky_exception() : owns_(true) {}
>     sticky_exception(sticky_exception& s) : owns_(s.owns_) {s.owns_ =
> false;}
> //    sticky_exception(sticky_exception&& s) : owns_(s.owns_) {s.owns_
> = false;}
>     ~sticky_exception() {if (owns_) {sticky_exception s; throw s;}}
> };

I promised to explain myself after a day or two and that time has  
come.  Thanks much to everyone who has responded.

sticky_exception is not my brain child.  It is modeling a behavior  
that someone else has proposed and I have been attempting to explore  
the ramifications of that behavior in as unbiased manner as possible.   
I did not want to mention the specific application because the  
application in question brings with it all manner of history and  
biased baggage.

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.

There exist opinions that the exception representing this action be  
"uncatchable".  So my question to boost was:  What will this mean to  
code in general, without thinking specifically about interruption?

I have attempted to present the uncatchable exception in such a manner  
that my position on it was not clear (in the hopes of receiving less  
biased comments).  However, now that the cat is out of the bag anyway,  
my own concern centers around things like:

class A
{
public:
    ...
    ~A()
    {
        try
        {
            do something that might throw
        }
        catch (...)
        {
            log or delay the exception
        }
    }
};

...

void foo()
{
     std::vector<A> v;
     ...
}

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.

-Howard