Re: [boost] Review Request: Boost Exception

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-11-14 01:59:03

Zach Laine wrote:
>> 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?

Most of the issues you point out are indeed errors in the documentation.

> 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:"

Fixed.

> 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.

Modified the documentation to point out that T must not be a reference.

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

This was by design. The constructors and the destructor are documented and 
are part of class exception's protected 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:
>
> <snip>

Fixed.

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

If you're talking about this example:

http://www.revergestudios.com/boost-exception/boost-exception.htm#basic_usage

I did not modify it, it had the semicolons.

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

Done. You can browse the source code, tests and everything here:

http://www.revergestudios.com/boost-exception/src/

> 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.

Since you bring it up, please do correct me if I'm wrong but *if* this is 
ever standardized, it could expand the semantics of std::exception. As far 
as I can see, this would not break existing code because the 
boost::exception constructors don't allocate memory and don't throw 
exceptions. Besides a pointer to the internal implementation (which is the 
only data member of boost::exception) there is no overhead; I could not find 
anything in 18.6.1 that boost::exception would violate.

> 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.

It shouldn't be make_error_info because that's not what it makes, it makes a 
boost::exception. I think that enable_error_info is more accurate than 
make_exception (English is not my native language).

> 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.

You can store any value in a boost::exception even if it can't convert to a 
string. For example, as I've done in the example at the end of the 
documentation, you can add a boost::weak_ptr<FILE> object in a 
boost::exception. It isn't reasonable to require the user to define a 
to_string overload for boost::weak_ptr, just to be able to store it in a 
boost::exception. Besides, even if you do require a to_string overload for 
boost::weak_ptr, that overload can only return something generic like 
"<weak_ptr>", which is similar to what you get from the fallback behavior of 
what() anyway.

In general, the value you store in a boost::exception could be something you 
can't print, but can be used to get you the thing you can print; this is 
beyond the scope of what().