Re: [boost] Review Request: Boost Exception

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2006-11-13 22:02:16

> I believe the proposed Boost Exception library is now mature enough for
> formal review.
>
> Please read the documentation at:
>
> http://www.revergestudios.com/boost-exception/boost-exception.htm

There are several problems with the docs linked above, besides those
that Dave Abrahams has already pointed out.  Did the code and online
docs just get out of sync somehow?

The enable_error_info function template is referred to as a class when
it is initially introduced: "This is accomplished by the
enable_error_info  class template. Here is an example:"

T must not be a reference in error_info_value<T>, because that would
introduce references to references in various places.  This should be
documented, or fixed using a reference type specialization and
boost::ref.

boost::exception's constructors and destructor are in its online docs,
but are not part of its public interface.

The actual signature of error_info type is:

template <class Name,class T>
typename error_info_type<Name>::type const * get_error_info( T const & );

but the online docs list it as this:

template <class Name,class T>
typename error_info_type<Name>::type get_error_info( T const & some_exception );

The tag struct declarations in the first example are missing semicolons.

It would be nice to have the actual headers linked to somewhere in the
online docs.

> Here is a direct link to the source code, boost build jamfiles and tests.
> Tested with MSVC 7.1, MSVC 8.0, GCC 3.4.4, and Comeau C++ 4.3.8:
>
> http://www.revergestudios.com/boost-exception/boost-exception.zip

As for the library itself, the name "exception" is fine within the
context of Boost, but it's going to collide with std::exception if
this is ever standardized.  Is there another name for this?  I have to
admit, nothing better springs to mind.

I think enable_error_info be called make_exception or make_error_info
(or make_[whatever]), in keeping with all the standard and Boost
make_*<> function templates.

What is the motivation for the Logging system's string conversion
behavior #3?  It seems that a compilation failure would be preferable
in most cases, since the silent failure of #3 to convert to a string
won't be noticed until the program is completely compiled and
executed.  I'd rather know at compile time.  This should at least be
an option.

Overall, I think this library looks very useful.  I'd like to see the
above things improved, but I'd really like to see this make it into
Boost.

Zach Laine