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:
> 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:"
> 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
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:
> The tag struct declarations in the first example are missing
If you're talking about this example:
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:
> 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
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().
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk