From: <williamkempf@[...]..> 
>  In catch_exceptions.hpp I wonder about the usefulness of capturing
>  every exception type in the std::exception heirarchy. If it's
>  beneficial to have the exact type reported then it seems that there
>  needs to be a way to specify types that will be caught. Otherwise
>  libraries that extend this heirarchy with their own exception types
>  will be reported as generic exception types while the standard
>  exception types that extend the heirarchy are more precise. I'd be
>  in favor of just catching std::exception types instead.

Exceptions displayed to the output should have these attributes:
1. Consiceness.
2. Unambiguity. (Is that a word? It's in my thesaurus, but not my
dictionary.)
3. Precision.

Currently, we have 1, a bit of 3, and debateably 2. I would propose that we
make a slight change to pick up all three as best as an implementation
allows. To do this we change our strings to std::exception (or derived):
, and also perform conditional compilation on whether a compilers provides
nicely readable names from RTTI. (I proposed using RTTI a while back, only
to be informed that some compilers use display the names of classes in a
cryptic fashion.) When nice names are available, we would just output
typeid(e).name + : , without the (or derived) since the actual class is
known.

Determining whether nice names are available isn't trivial, but isn't too
hard either. We can certainly play it conservative and default to assuming
that nice names are not available, and then for each compiler that supports
nice names and has RTTI enabled, turn on the boost macro that causes
catch_exceptions to use precise class names. Hopefully most compilers make
it easy to know whether RTTI is enabled (or just always have it enabled); a
quick look at VC6 shows a _CPPRTTI macro.

I'll save paying my comments to the Boost Unit Test Tolls :-) and other
aspects of the Boost Test Library until formal review time.

Following-the-no-new-topics-rule-of-cross-cross-examinationly yours,
Ed