Hello Howard, if I understood the semantics correctly, I see a particular situation where using such an exception could lead to hard to trace errors. Suppose I have the following setup: struct Error { ... }; struct SeriousRuntimeError : Error, sticky_exception { ... }; void log_error(Error const& error); And now somewhere within my program I have: try { // ... } catch (SeriousRuntimeError e) { // ... do something ... log_error(e); // ... do some more things ... } Up to now all is fine and the catch handler behaves as intended. Now suppose the maintainer of the Logging functions for whatever reason changes the log_error() signature to expect it's argument by value. All of a sudden the call to the log_error() function would rethrow the exception upon it's completion, thus skipping the remainder of the catch-handler. Of course I could circumvent this situation by using the proposed reset() method, but since sticky_exceptions' use in the class hierarchy might not be obvious to the user, I think it's bound to cause problems in collaborative situations. Best regards, Kimon