williamkempf@[...].. wrote:
>  A) An exception type may not be derived from a std::exception type.

True.

>  B) The user might want to register special error handling beyond
>  simple output of the cause for failure (execution_tools or even
>  catch_exceptions() may be used outside of test harnesses).
>  C) The user may want to override previously registered handlers to
>  do specific actions instead of or in addition to the previous
>  behavior.

In response to B + C, if the user wants to deal specially with some
exceptions, I looks like a regular try { } catch(my_exception&)
block around his code is what he wants. I don't see at the moment
why this should be wrapped in some external library where you have to
register a handler etc.

However, I do recognize that the pattern presented is an ingenious
one to offload exception type detection to somewhere else, thus allowing
code re-use. Probably some future boost library can explore this a
bit more and make a nice service out of it. In general, the need for
this seems to point out design problems in the exception design, though.

Jens Maurer