From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-11-14 14:35:28
Zach Laine wrote:
>>> 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:
> 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
>>> 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.
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk