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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to