Arguments for not using throw()

[Johann Gerell]

Hi all,

Since last summer, my group has been putting throw() into the code base
as a general guideline where applicable. I've disliked it from the
beginning, since I see it as a micro-optimization at the cost of no
stack unwinding (possible data corruption) when an exception is thrown
somewhere anyway, despite the best beliefs of the programmer adding the
throw().

Now I've determined to take up the discussion for real to get rid of
the throw() and I thought I pass this ball to you gentlemen:

What are the best arguments _against_ throw(), and for the sake of
completeness _for_ throw().

I know my Sutter and Meyers (et least their views on this issue), but
do you all have something to add to their input? I'd like to be well
prepared, so I can persuade those that have no strong opinion in either
direction, and perhaps even the originator of the idea...

[Johann Gerell]

I maybe should have added that we don't even implement a terminate
handler for the case when a throw() function throws...

[Alan Johnson]

Johann Gerell wrote:

Hi all,

Since last summer, my group has been putting throw() into the code base
as a general guideline where applicable. I've disliked it from the
beginning, since I see it as a micro-optimization at the cost of no
stack unwinding (possible data corruption) when an exception is thrown
somewhere anyway, despite the best beliefs of the programmer adding the
throw().

Now I've determined to take up the discussion for real to get rid of
the throw() and I thought I pass this ball to you gentlemen:

What are the best arguments _against_ throw(), and for the sake of
completeness _for_ throw().

I know my Sutter and Meyers (et least their views on this issue), but
do you all have something to add to their input? I'd like to be well
prepared, so I can persuade those that have no strong opinion in either
direction, and perhaps even the originator of the idea...

You might check out Boost's rational for not using exception specifications:
http://www.boost.org/more/lib_guide....-specification

To paraphrase, smart compilers will realize when a function cannot
throw, and will do all the same optimizations as if you'd added throw().
Dumb compilers will often make pessimizations such as turning off
inlining or adding try/catch blocks.

-Alan