By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,146 Members | 1,614 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,146 IT Pros & Developers. It's quick & easy.

Arguments for not using throw()

P: n/a
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...

Jul 23 '05 #1
Share this Question
Share on Google+
2 Replies


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

Jul 23 '05 #2

P: n/a
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
Jul 23 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.