Re: [boost] Do we need a boost_exception class or idiom?

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-20 17:47:13

"William E. Kempf" <wekempf_at_[hidden]> 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
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution