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