[boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION [was RE: Boost and exceptions]

Subject: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION [was RE: Boost and exceptions]
From: Pete Bartlett (pete_at_[hidden])
Date: 2012-06-25 17:32:05

> On 06/22/2012 02:23 PM, Stewart, Robert wrote:

>There is no Boost policy that requires Boost.Exception support.  If you
think there should be, >then lobby for it. 

This thread has pushed me in the direction that this is the way to go. Here
are some specific policy change proposals:

1) Mandate that all throws should be through BOOST_THROW_EXCEPTION and
enforce through Boost.Inspect. or:
2) Strongly suggest in developer documentation that they should be through
BOOST_THROW_EXCEPTION but drop short of mandating. or:
3) Better document and formalize existing practice (that user-visible
exceptions should derive from std::exception, and that a developer may use
BOOST_THROW_EXCEPTION and boost::throw_exception and may respect
BOOST_NO_EXCEPTIONS, but isn't obliged to do so)

Pros for 1) and 2):

- All libraries naturally support the BOOST_NO_EXCEPTIONS config without
further work on their part.
- All libraries benefit fully from Boost.Exception functionality.
- All libraries benefit from future improvements to Boost.Exception (e.g.
possible improvements relating to cross-thread exception handling)

Cons for 1) and 2):
- Always paying for the cost of #including <boost/throw_exception.hpp>
- All libraries are dependent on - and therefore become vulnerable to any
future breakages (if any) in - Boost.Exception.
Cons for 1)
- This would (a little) reduce the autonomy that Boost authors have to
implement as they see fit. Historically Boost authors have great individual
freedom and imposing restrictions may be unattractive to (volunteer) devs.

FWIW, I'm firmly in favour of 1). Re the cons, I don't think the cost of
extra includes will be the straw that breaks the camel's back, particularly
when users are already likely to be putting Boost in a PCH. Re the second
con, I think Boost should collectively be prepared to eat its own dogfood -
if Boost.Exception does ever break, users will be affected too and so any
breakages in Boost code will act as an early warning system when testing. Re
the third con, I think this is a fair point, but all we are really doing is
asking "throw e;" to be replaced by "BOOST_THROW_EXCEPTION(e);" so I don't
think creativity is being hindered too much in this case.

Thanks for listening!
Pete