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-25 18:22:25

On Fri 3/25/2011 2:54 PM, Emil Dotchevski wrote:
 
> On Fri, Mar 25, 2011 at 12:17 AM, Vladimir Prus wrote:
>
> > I think a different question is worth asking -- did you measure any of above?
>
> No, I did not measure the overhead of throwing and catching class A
> deriving from class B and std::exception vs. throwing and catching
> class A deriving from std::exception only.

AFAIK, exceptions aren't exactly cheap, no matter what.  Therefore, as long as BOOST_THROW_EXCEPTION() doesn't increase the cost by like an order of magnitude, I wouldn't much mind.

> Honestly, I've never measured the speed of throwing and catching any
> exceptions on any platform -- I tend to focus on whatever the profiler
> points me to.

It's when you start insisting that it must be used everywhere that something like 50% overhead can start to be a problem.  It just might be that exceptions are a hot spot, in a particular design or context (maybe Boost.Python is a good example?).  If you force people to use BOOST_THROW_EXCEPTION() and it's not essentially free, then you're limiting the optimizations they can do.  And if some of those are cases where no benefit can be derived from its usage (i.e. because they're internal exceptions that are always caught and the code won't work properly when compiled without them), then such a policy starts to look questionable.

I haven't seen anyone come out against BOOST_THROW_EXCEPTION(), in the general case.  Clearly, it's provides useful benefits to users and should be encouraged - even with the help of automated tools like inspect.  I'm just not convinced that an absolute requirement would be a good thing, especially when tools can otherwise still potentially catch most unintentional omissions.

Matt