Hello, I am requesting comments, both for and against a "sticky exception". A sticky exception is one in which once thrown, is very hard to catch and handle, without an implicit rethrow. This represents some condition which the thrower believes is sufficiently severe that the application (or thread) should clean up resources, but not be allowed to continue, even with a catch (...) which does not rethrow. This can be implemented very simply with a class that owns the right to rethrow on destruct, and passes that right along within its copy constructor: 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;}} }; Please go ahead and experiment with such an exception. I would like to hear your experiences both good and bad. Here is one test driver: #include <iostream> void f3() { try { sticky_exception s; throw s; } catch (...) { std::cout << "catch in f3\n"; } std::cout << "f3 return\n"; } void f2() { try { f3(); } catch (...) { std::cout << "catch in f2\n"; } std::cout << "f2 return\n"; } void f1() { try { f2(); } catch (...) { std::cout << "catch in f1\n"; } std::cout << "f1 return\n"; } int main() { try { f1(); } catch (...) { std::cout << "catch in main\n"; } std::cout << "main return\n"; } which should output: catch in f3 catch in f2 catch in f1 catch in main and then terminate abnormally. Note that no function returned normally (no "return" statements printed). One possible variation of the above design is to place a reset() method in the exception which would cure its suicidal tendencies: 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;}} void reset() {owns_ = false;} }; One could then catch it and reset it: catch (sticky_exception& e) { e.reset(); std::cout << "sticky_exception fully handled\n"; } Note that with the above modification, catch (...) would still always automatically rethrow a sticky_exception. One would need to add the extra catch(sticky_exception&) shown above to get back the old behavior of catch (...). Do you see a use for such a class? Would you use it? Would you want libraries you're using to use it? Do you have real world example conditions which fit this use case? Or is it just evil (and why)? Thanks much, Howard