Subject: Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION [was RE: Boost and exceptions]
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2012-06-25 19:49:07
On Mon, Jun 25, 2012 at 2:13 PM, Jeffrey Lee Hellrung, Jr. <
> On Mon, Jun 25, 2012 at 2:32 PM, Pete Bartlett <pete_at_[hidden]>
> > > 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.
> > 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
> > BOOST_THROW_EXCEPTION and boost::throw_exception and may respect
> > BOOST_NO_EXCEPTIONS, but isn't obliged to do so)
> Regarding (1) and (2), I think one should have the option to simply use
> boost::throw_exception. The additional file/function/line info may not be
> very useful within a templated implementation detail, and, in any case,
> such info is likely only useful/usable in a debugging context.
boost::exception stores the BOOST_THROW_EXCEPTION information in a custom,
more efficient way than other data. The only overhead is the potential
bloat from BOOST_CURRENT_FUNCTION, which now can be controlled (see ticket
At least in my experience BOOST_THROW_EXCEPTION is very helpful in
combination with boost::diagnostic_information. In my development
environment, I can double-click the message to go to the location of the
throw, which makes it easy to set a break point and run again to see the
context in which the unexpected exception happens.
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk