A Real-life Story about exception specification

Today, just before I thought I'd finish my day and go home, I got a urgent problem. One of our component kept coring, making services unavailable to clients.

Investigation started right away and we found the cause after a while. The cause is quite simple but unexpected.

The reason is we have a function specified with a exception specification. For those who are not familiar with the exception specification, it's the famous throw(A) that you can put after a function declaration or definition. It's used to tell compiler what exceptions should be allow to be thrown in the function, particularly, if nothing is in the (), that means the function is not allowed to throw anything.

Well we have one such function that with a throw() however, it DO throw an exception. So what happens? The exception is caught and treated as unexpected, then terminate() is called, then terminate() calls abort(), program aborts with a core (SIGABRT 6).

It's NOT hard to understand all of this, but we had a painful time to find out that it's actually this exception specification had caused the problem, it's in the same line as the function definition, far away from when the line where actually throws something.

It's a shame that after years of debate on this topic, we still fail on that. Here are some links:
http://www.gotw.ca/publications/mill22.htm
http://www.gotw.ca/gotw/082.htm
http://www.boost.org/development/requirements.html#Exception-specification
All those gurus suggest NOT USING EXCEPTION SPECIFICATION !

After beaten senselessly, now I remember, never write a exception specification.

Also I have to put another point on that, a function with exception specification is just a trap for other programmers who is working on it, it may not notice the very existence of the throw() and throw something in the function body, or even harder to prevent, he may just call a function that throws inside.  I'm such a victim, modified a function with throw() but throw something.