On 10/22/07, Alexander Nasonov <alnsn@yandex.ru> wrote:
As already pointed out by many people, library name is misleading. I'd expect from a library named Boost.exception that:
- it provides functionality missing in std::exception (clone is one example),
As pointed out by me and by others, cloning is outside the scope of Boost Exception.
- it recommends deriving all boost exception classes from boost::exception and
I'm confused; this is exactly what Boost Exception recommends.
- wrapping standard exceptions with correspondent boost exceptions in boost::throw_exception.
boost::exception is designed as an extension of std::exception. You don't wrap standard exceptions with correspondent std::exception, you just derive std::exception. What do you mean by "wrapping"?
The library doesn't have enough features to cover problem domain or they are not well documented.
Example shows how to attach additionaly information to FILE but it would be much better to demonstrate how information is added at each layer and then presented to end user.
The example included in the documentation demonstrates all aspects of using boost::exception: - how to store information in an exception object at the time of the throw, - how to append information to an existing exception object at some intermediate level, - how to access the information at the point of the catch, to format a user-friendly message. This example seems complete to me, but it is hard for me to imagine how it would work on someone without much knowledge of boost::exception. I am very interested in ideas on how to make this example better.
Other important case is stacking up information as an exception is being processed. Stack trace is a good example.
Stack trace can not be implemented in a platform independent manner; we need the collaboration of the Boost community to implement it correctly on multiple platforms. It is a debugging feature that once implemented, will appear automatically in the ::what() message. Other "stackable" information can be stored in boost::exceptions by storing a container object (such as std::vector) using error_info, then accessing it by get_error_info to add more elements.
Also, it should be clear how library handle bad_alloc. In some situations, it's fine to rethrown bad_alloc instead of original exception but more fine tuned behavior is require in other situations.
If you run out of memory at just the right time when using Boost Exception, you might throw bad_alloc instead of the exception you wanted to throw. However, this is not specific to boost::exception; for example, you'll get the same behavior from any exception object that contains a std::string. In general, failure to throw an exception can not be "fine tuned". For example, with or without Boost Exception, throwing requires memory allocation, and when that allocation fails, something else (typically not very friendly) happens. Emil Dotchevski