Boost logo

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