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

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. <
jeffrey.hellrung_at_[hidden]> wrote:

> On Mon, Jun 25, 2012 at 2:32 PM, Pete Bartlett <pete_at_[hidden]>
> wrote:
>
> > > 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)
> >
> [...]
>
> 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
#6450.)

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.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode