Great g++ bug! Local destructor isn't called!

[Eljay Love-Jensen]

Hi Matt,

 >Just out of curiosity, what is the reasoning for this?  Is this for g++ 
specifically, or C++ in general?

It's for C++ in general.

The rational (and experience) is that if someone puts a throw(something) 
specification on a function or method, and that routine relies upon other 
code, and that code is unspecified OR the throw specification changes AND 
the unsuspecting dependent code with the throw specification or try/catch 
wrapper is not updated when the called code changes... k-boom.

In that situation, the program terminates buh-bye sayonara.  The user's 
work is lost, customer service gets lots of calls from irate customers, 
developers get to work 80 hours of emergency crunch time to resolve the bug 
-- all because of throw(something) specifications that do only harm, and do 
no good (since they are not used at compile time).

PLUS, having a throw(something) specification on a function or method 
incurs run-time overhead (!).  Remember the C++ rule, your not supposed to 
pay for something if you don't put it in?  The throw(something) 
specification is checked at runtime, and is something that you pay for in 
performance.

Not that people should be using the C++ exception mechanism for regular 
flow control... but some people do.

How does this happen?  Say, for instance, development is done in two 
different teams that rarely communicate with each other.  Someone misses 
that a header file changed with a new or altered throw(something) 
specification... bug in waiting.

You could program defensively (and maybe that's not a bad idea).  But now 
you MUST enforce that all routines that have a throw(something) 
specification MUST have a try {} catch(...) {} block at the outermost level 
of the body.  And what are you gaining?  You are consuming all exceptions 
pell-nell, cannot handle them (presumably), while somewhere up the stack 
perhaps there was a routine which could have handled the mystery 
exception.  To what benefit...?

More code, less readability, less maintainability, more risk, more chances 
for things going awry IN THE PRODUCTION CODE.  Not good.

--Eljay