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_usag... 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().