I have read something on IBM's site about exception specification and pointers to functions:

void (*f)();
void (*g)();
void (*h)() throw (int);

void i() {
f = h;
//   h = g;  This is an error.

IBM says:

The compiler allows the assignment f = h because f can throw any kind of exception. The compiler would not allow the assignment h = g because h can only throw objects of type int, while g can throw any kind of exception.

But I tested the code in VC++, DEVC++ and CodeBlocks, no error anywhere.

Any explanations?



5 Years
Discussion Span

If you compile with a very strictly standard compiler, then that line will indeed produce a compilation error. For instance, you can try it with the online Comeau compiler (pretty much the most standard-compliant compiler that exists).

I'm not surprised that many compilers do not care about this exception-specification-related rule. Most compilers are not strictly compliant with the standard, they cut a few corners short (usually nothing major), especially with things that nobody cares about. Exception specification is one of those things. It's just a cost-benefit thing here. If you want to enforce this rule of the standard, you need to do static analysis of the code to cross-check exception specifications, and it can be quite hard (and wasteful). Then, most of the actual purpose of exception specification is for run-time halts when an unspecified exception tries to propagate out of a function, this feature has no purpose under static analysis (during compilation), it only serves a purpose after compilation. Then, considering that there are real problems with the actual usability of exception specifications in general (the intent is good, but the design is flawed in a way that makes them pretty much useless), this makes exception specification a very rarely used feature, whose use is generally discouraged (except for the "no-throw" specification), and the compilers support it mostly for legacy reasons (and with the introduction recently of the noexcept specification, I think the long-term aim is to get rid of exception specification altogether). Conclusion: nobody cares much about exception specs, neither do the compiler-vendors, so they support it as long as it's not too hard to do, and they won't break a sweat trying to comply with one stupid little rule that nobody cares about. In this case, most compilers are simply more permissive than the standard, which is not so bad in this case.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.