Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)

Subject: Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
From: Gruenke, Matt (mgruenke_at_[hidden])
Date: 2011-03-24 23:03:23

At Thu 3/24/2011 9:04 PM, Dave Abrahams wrote:

At Thu, 24 Mar 2011 17:49:55 -0700,
Emil Dotchevski wrote:
> 
> On Thu, Mar 24, 2011 at 4:50 PM, Dave Abrahams <dave_at_[hidden]> wrote:
> > At Thu, 24 Mar 2011 11:27:23 -0700,
> > Emil Dotchevski wrote:

> > > For example, "it buys nothing, because the library can't really work
> > > as coded without exception support."  Such is the case for
> > > Boost.Python, I believe.
> >
> > Whether it makes the library useful in BOOST_NO_EXCEPTIONS builds is
> > best left for the user of the library to decide. 
> 
> No, really.  Python throws exceptions as a matter of course (e.g. loop
> termination).  These get translated into C++ exceptions.

I really have a problem with the suggestion that using BOOST_NO_EXCEPTIONS should be so risky.  IMO, if a library isn't designed to work with without exceptions, then it should be automatically disabled.  If the user really wants to take its chances, then it can try to force the library to build.  Users operating in exception-restricted circumstances deserve no fewer promises than the rest of us.

> > Besides, even if the library remains useless in BOOST_NO_EXCEPTIONS
> > builds, I wouldn't say that BOOST_THROW_EXCEPTION buys nothing.
> 
> What does it buy in this case?

I'll volunteer an answer to a different question: "what does it cost?"

I did a little bit of performance testing and found BOOST_THROW_EXCEPTION to add about 45% overhead (CPU: Intel Xeon X5570;  compiler: gcc-4.2.3;  optimization: -O2) vs straight 'throw' of simple std::exception-derived class.  So, it's not exactly free.  That said, neither is blazingly fast.

The reason I thought use of BOOST_THROW_EXCEPTION could be litigated on a per-library basis is that I can see someone not wanting to pay for that overhead (or perhaps being forced to accept some other side-effect) for an exception that's entirely internal to a library.  But in the absence of such a reason, I'd agree that it should be strongly encouraged.

To me, this thread feels a little like a witchhunt.  When used judiciously, exceptions can significantly simplify interfaces and the code which uses them.  I hope not to see them made optional in any library where doing so would necessitate that interfaces or usability be compromised.  So, while I would like to see Boost libraries accommodate those in exception-restricted circumstances, I also don't want to see them get watered down, as a result.

Matt