Re: [boost] Review Request: Boost Exception

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-11-14 19:07:43

>>> <snip>
>>> 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".
>
> Well, I was specifically thinking of this sentence: "If
> boost::exception derives from std::exception, this would create a
> problem for enable_error_info: it is designed to make it easier to
> integrate Boost Exception with existing exception class hierarchies
> which can not be modified without a risk of breaking existing
> exception handling code."  Standardizing boost::exception as a
> separate class would be more useful with respect to
> non-std::exception-based exception classes.

Hypothetically speaking, if boost::exception functionality is directly 
supported by std::exception, std::enable_error_info<T>'s behavior would be 
to "return an object of unspecified type which derives publicly from 
std::exception and T". You wouldn't need to call enable_error_info with a T 
that derives from std::exception.

>>> <snip>
>> 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<>.
> <snip>
>
> It comes down to the fact that boost::exception::what() advertises
> that it produces output for each associated datum, but currently it
> silently fails to do so if I forgot to provide the correct overload of
> operator<<.  Since we're dealing with exception handling here, many
> times what() will be used to print out a bit of info right before an
> abort.  For hard-to-reproduce exceptions, you really want all the info
> you can get, and finding out that you forgot to define the right
> operator<< overload at runtime is going to be really painful in many
> cases.  While the increased usability of substituting "<unknown>" will
> probably be preferable for most use cases, it is certainly not for
> others.

Peter Dimov suggested that another possibility is to fail if a suitable 
to_string overload is not found, like you want, but to be able to specify 
that a particular tag's value is not printable:

tag_whatever: error_info_value<T,false> { };

or something similar.

>> 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.
>
> Sorry, I don't understand this sentence.  Could you say it another
> way?

I now realize that what I meant was really a separate issue from what(), but 
since you're asking I'll clarify what I meant.

I say "your program" to stress the fact that the error_info that arrives at 
catch sites is not only up to the libraries you use (where some exceptions 
originate), because the particular program (or application) you're working 
on can add its own error_info to any exception. So what I meant is that 
within the broader context of the application, there may be a requirement 
that each exception of type T must have error info for tag_a, tag_b, and 
tag_c, so if you catch a T that doesn't have them all, you can report it as 
a bug. Assuming that using tag_a, tag_b and tag_c you can format a 
user-friendly message, the fact that tag_b's value won't show up in what() 
seemed unimportant.

Ultimately I agree that what() is an important debugging tool, I think we're 
on the same page, we just need to find the correct behavior.

>> 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?
>
> Well, that's a possibility, but consider this:  If such a warning were
> on all the time, some users would complain, since many users work
> under the rule that their code must build without warnings.  So then I
> think you'd probably end up defining something like the macro above
> anyway, so users could see the warnings or turn them off.
>
> Once you've got the macro, I think the users that turn on the warning
> behavior would prefer an error, since the whole point of turning it on
> is to catch those places in which string conversions are needed.

Agreed.