From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-11-20 08:53:21
Boost libraries often define exception classes, usually derived from the
standard library exception hierarchy. Users sometimes ask for further
refinement, so the library ends up with its own hierarchy.
For example, the Filesystem library started out with
boost::filesystem::filesystem_error, but reviewers asked for more specific
exceptions at least for the most common errors (like "file not found".) The
suggested plan was to add one or two derived error types now, and more as
experience dictates.
That works well for callers who know exactly what exception types will be
thrown, but also implies that libraries like Boost.Test which try to catch
specific exception types (for better error reporting) have to be
continually updated to reflect new boost exceptions being added. An
exception class which was self-explanatory would be better for these uses.
I try to cope with that need by a lengthy what() message.
In another thread, Peter Dimov has pointed out that providing a what()
message that can be used as a key is helpful in internationalizing
messages.
Has anyone run into a comprehensive attack on these and similar exception
class problems? Is there a better way than each Boost developer just
hacking together individual exception classes? Could we do better with a
Boost exception class or idiom?
--Beman