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