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