Deriving from boost::exception effectively decouples the semantics of a failure from the information that is relevant to each individual instance of reporting a failure with a given semantic.
In other words: with boost::exception, what data a given exception object transports depends primarily on the context in which failures are reported (not on its type.) Since exception types need no members, it becomes very natural to throw exceptions that derive from more than one type to indicate multiple appropriate semantics:
diff --git a/doc/motivation.html b/doc/motivation.html index c90e4f3..7d8f204 100644 --- a/doc/motivation.html +++ b/doc/motivation.html @@ -123,7 +123,7 @@ catch( boost::exceptionException Types As Simple Semantic Tags
+Exception Types as Simple Semantic Tags
The program above outputs "whoops!" because the conversion to std::exception is ambiguous.
-The overhead introduced by virtual inheritance is always negligible in the context of exception handling. Note that virtual bases are initialized directly by the constructor of the most-derived-type (the type passed to the throw statement, in case of exceptions.) However, typically this detail is of no concern when boost::exception is used, because it enables exception types to be trivial structs with no members (there's nothing to initialize.) See Exception Types As Simple Semantic Tags.
+The overhead introduced by virtual inheritance is always negligible in the context of exception handling. Note that virtual bases are initialized directly by the constructor of the most-derived-type (the type passed to the throw statement, in case of exceptions.) However, typically this detail is of no concern when boost::exception is used, because it enables exception types to be trivial structs with no members (there's nothing to initialize.) See Exception Types as Simple Semantic Tags.