"William E. Kempf" <[EMAIL PROTECTED]> writes:
>> There are workarounds for that problem. See
>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254
>
> Thanks for the link. Comments:
>
> * I personally don't agree with the rationale that not throwing
> bad_alloc when constructing from a string is not necessarily a bad
> thing. As bad as exception specifications are, they are at least
> useful as documentation
Not very. Don't forget that derived classes pass.
> and this automatically adds another exception type to the list that
> may not have otherwise been there.
Not unless your compiler is broken. Exception specifications are
strictly enforced at runtime.
> * It's nice to know that the copy constructor is technically not allowed
> to throw, but how many implementations get this wrong today?
None, to my knowledge.
> At the very least, it would be nice if we had a boost::exception (derived
> from std::exception) as a base, which included the const char* constructor
> to eliminate the problem with the string constructor,
There is no problem with the string constructor, because that
constructor doesn't exist in std::exception.
> and that ensured nothrow copies.
You can't ensure that in a base class. A derived class can always
throw in its copy-ctor.
>>> and the string isn't language neutral.
>>
>> Neither is your source code. You don't need to use the string for
>> language-neutral messages.
>
> No, but it is desirable to provide language neutral strings
What's a language-neutral string? "42"?
> that describe what exception was thrown, and possibly why and/or
> from where, etc. This isn't to say that what() is bad because it's
> not language neutral
?? It's as language-neutral as you make it. It's just a string.
> only that there's (at least in some circumstances) a desire for a
> language neutral description of what went wrong.
Localization should not the be the job of an exception class.
>>> I'd prefer a what() that returned a key which never had to be
>>> allocated
>>
>> It does; you can always return a string literal.
>
> Uhm... yes, so long as you can supply that key with out having to
> use the string constructors from most of the standard exceptions.
?? Aren't we talking about whether a boost::exception is needed?
Wouldn't that just be derived from std::exception? What's the
problem?
>
>>> and possibly could be used to index into a catalog of language
>>> neutral strings for output.
>>
>> Existing what() does that.
>
> How so? I can think of a few hacks, but none seem completely
> satisfying.
std::map<char const*, std::string, compare_cstring>?
>> I don't think what() needs to be addressed. The kind of polymorphic key
>> that could carry arbitrary extra data surely *forces* dynamic
>> allocation, so it wouldn't be an improvment.
>
> I never claimed the key need be polymorphic, and thus dynamic allocation
> isn't necessarily forced.
OK, but I claim char const* does give us very nice polymorphism and
can even use static allocation.
> std::exception is nearly the perfect design (it's the logic_error and
> runtime_error branches in the heirarchy I have problems with, though as
> you pointed out there are ways to fix those). The only problem is how you
> allow the strings to be made language neutral. From what you said above,
> I assume you think there's a solution to that, but I don't see it. Care
> to point out what I'm not seeing?
If there's an answer, it's in a different domain. I don't think that
belongs in an exception class.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
