|
Boost : |
From: Kimon Hoffmann (Kimon.Hoffmann_at_[hidden])
Date: 2007-09-14 15:09:40
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk