Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-20 16:48:11

"William E. Kempf" <wekempf_at_[hidden]> writes:

> Fernando Cacciola said:
>> I'm not sure if a boost exception class is *needed*, but I see no
>> problem in having one.
>> Anyway, IIF such an exception class is defined, I *strongly* encourage
>> (as I did in the past) that it provides:
>> virtual void raise() const
>> {
>> throw *this ;
>> #endif
>> }
>> and that boost libraries throw such exceptions *only* by calling
>> .raise(): i.e. never with a throw expression directly in the user code.
> template <typename T>
> void raise()
> {
> throw T();
> #endif
> }
> template <typename T, typename P1>
> void raise(const P1& p1)
> {
> 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.

> 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

> which may change the type of exception thrown

There are workarounds for that problem. See

> and the string isn't language neutral.

Neither is your source code. You don't need to use the string for
language-neutral messages.

> I'd prefer a what() that returned a key which never had to be
> allocated

It does; you can always return a string literal.

> and possibly could be used to index into a catalog of language
> neutral strings for output.

Existing what() does that.

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

                       David Abrahams
   dave_at_[hidden] *
Boost support, enhancements, training, and commercial distribution

Boost list run by bdawes at, gregod at, cpdaniel at, john at