Re: [boost] Review Request: Boost Exception

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-11-14 14:35:28

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

OK I am confused. The source code is available and has been available for a 
few months now, when I did the preliminary submission, there were some 
discussions, changes in the design, etc. Starting this thread, with the 
Review Request subject line, I thought that I am submitting the library for 
official review. Did I miss something? What source files are you talking 
about?

>>> 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 guess you can add "because that way it could become std::exception" to 
"why doesn't boost::exception derive from std::exception".

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

When you say "useful output" you do realize that the output from what() is 
not user-friendly, right? Displaying the information relevant to a 
particular error is a separate issue beyond the scope of boost::exception. 
The user-friendly message is composed based on the type of the exception 
object, and the contained values recovered by get_error_info<>. Your program 
has to "know" what values to expect in a particular exception type, and 
you're free to report missing values that are required by design.

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

It seems to me that your motivation with this issue is to make the output of 
what() more user-friendly, and more useful. I am all for making what() more 
useful, but at the same time I think that such efforts must not interfere 
with the ability to store *any* value type in a boost::exception.

Perhaps we can make the compiler issue a warning if you add to a 
boost::exception value type that can't be converted to string? What do you 
think?