Re: [boost] Exception late review

From: Emil Dotchevski (emil_at_[hidden])
Date: 2007-10-22 14:36:15

On 10/22/07, Alexander Nasonov <alnsn_at_[hidden]> 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