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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-11-20 17:40:51

David Abrahams said:
> "William E. Kempf" <wekempf_at_[hidden]> writes:
>> Fernando Cacciola said:
>> template <typename T, typename P1>
>> void raise(const P1& p1)
>> {
>> #ifndef BOOST_NO_EXCEPTIONS
>>    throw T(p1);
>> #endif
>> }
>>
>> // other such overloads if needed
>>
>> void foo()
>> {
>>    raise<std::logic_error>("my logic error");
>> }
>>
>> Is this not better?  It works even with the standard exception types,
>> no modification to the implementation.  Not a 100% solution for what
>> you want, since there's still exceptions that can be raised outside of
>> Boost code, but maybe it's enough.
>
> This seems like a very bad solution. It requires solving the
> forwarding constructor problem, for one thing. boost::throw_exception
> doesn't have that problem.

A better solution yet, though I wouldn't classify what I had as "very
bad". ;)

>> I dislike the standard exception what(), since (with most of the
>> exception types) this requires dynamic allocation of the string,
>
> It's not what() that imposes this constraint, but the constructor
> signature.

Yep.  That's why I said "with most of the exception types", though I have
to admit this was a bad description of the problem.

>> which may change the type of exception thrown
>
> 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,
and this automatically adds another exception type to the list that may
not have otherwise been there.

* It's nice to know that the copy constructor is technically not allowed
to throw, but how many implementations get this wrong today?

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, and that ensured
nothrow copies.

>> 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 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, only
that there's (at least in some circumstances) a desire for a language
neutral description of what went wrong.

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

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

>> Maybe type_info::name() would be enough for a human readable string,
>> but there's two issues with this: it doesn't carry any extra data (for
>> example, an invalid_argument exception could indicate which argument
>> was invalid) and it's not easily used to index into
>> language neutral strings.  But if there's anything a boost_exception
>> base type should do, it's address the what() issues.
>
> 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.

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?

William E. Kempf