"William E. Kempf" <[EMAIL PROTECTED]> 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 >> { >> #ifndef BOOST_NO_EXCEPTIONS >> 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() > { > #ifndef BOOST_NO_EXCEPTIONS > throw T(); > #endif > } > > 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. > 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. > 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 > 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 [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