Re: [boost] Review Request: Boost Exception

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2006-11-14 13:13:26

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

Fair enough.

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

Sorry, I meant to say the first example in "Frequently Asked
Questions".  Those are missing the semicolons. In general, I think it
will be easier for you if you take working, compiled code, and cut out
the pieces you want to include in your docs, so that you know
everything in the docs at least compiles.

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

I actually meant that the online docs that you intend to submit for
review would benefit from having the library's source files included
as well.

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

That's correct, but I think a likelier scenario for standardization
would be to include Boost.Exception as-is, so that it a) does not
affect any current standard library or user code, and b) retains its
full usefulness (I'm thinking here of your rationale section "Why
doesn't boost::exception derive from std::exception?").  Anyway, this
isn't a major objection, just something to think about.

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

Alright, then it sounds like if it makes an exception, it would be
better to call it make_exception than enable_error_info.  This follows
the example of std::make_pair, etc.

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

I agree with your point, but it would also be nice to have a strict
mode, so that the compiler could catch all the places that the default
string was going to be produced.  If I decide that I want all
boost::exception instances in my code to produce useful output for all
their contained data (a reasonable expectation for many validation
schemes), I have no way under the current design of doing so.  My only
option right now is to inspect the code or run the code, trying to
provoke all the exceptions.  These are error-prone ways of verifying
that the what() output is whatw I want, obviously.  So I'd like to see
something like BOOST_EXCEPTION_STRICT_WHAT, that when defined causes a
compile failure for behavior #3.

Zach Laine