Both C++ and Java (and other programming languages as well) support a notion of exception specifications. The design and even the desirability of these specifications is controversial. In C++, for example, the exception specifications are enforced at run time; if a function throws an unexpected exception the running program is (by default) aborted. In Java the exception specifications are enforced statically. If a method tries to throw an unexpected exception the program won’t compile. Which approach is better?
Exceptions are a dynamic process. The precise exceptions thrown by a program and where they are handled depend on the inputs given to it and on the execution path taken by the program as it runs. One might reasonably wonder if all possible exceptions that a program might throw are handled somewhere. Can this even be determined statically? My guess is that the question is undecidable in the general case. I don’t have a proof of this, but I’d be surprised if it was otherwise. Thus any static analysis must necessarily be either unsound or incomplete or both. In the case of exception specifications this means that either the analysis misses some exceptions that might be thrown and thus says all exceptions are handled when they are not (unsound), or the analysis forces the programmer to handle exceptions that in fact can never be thrown (incomplete).
Many exceptions have the potential to arise very often. For example in Java the null pointer dereferencing exception could potentially arise whenever an object or array is accessed. Requiring this exception to be part of an exception specification would essentially mean that every method would need to be decorated with that exception (and then what would that really tell you?). To avoid this Java’s exception specifications are unsound; certain exceptions, the so called “unchecked” exceptions, do not need to be covered by exception specifications. However, this means that the static analysis done by the compiler doesn’t really answer the question you’d like answered: are all possible exceptions handled in some way? Yet despite that, Java’s handling of exception specifications is also incomplete; among checked exceptions it is still possible that the compiler will force you to handle an exception that, under your specific conditions, can’t occur.
C++ checks exceptions specifications dynamically. This has the advantage of being precise; only those exceptions that actually do violate the specifications are reported. However, this leaves open the problem of what should be done when such a violation is detected. The program is already running at that point so the way in which this error should best be handled is likely to be application specific. Aborting the program outright might be reasonable in some cases, but probably not in most cases. C++ allows the programmer to translate unexpected exceptions into expected ones (using unexpected handlers) but this has the disadvantage of throwing away information about the original exception (although one could imagine an unexpected handler that logs the original exception in some way before translating it).
Yet there are issues with exception specifications that transend the static vs dynamic question. For example an exception thrown in a call back function that propagates through a third party module and is eventually handled by the client of that module should be perfectly well behaved. Yet the exception specifications in the third party module can’t possibly know about the client’s exceptions. There are also questions regarding the handling of exception specifications in generics or templates, etc. Many issues with exception specifications have been described with proponents on both sides of every argument. One is left with the distinct impression that the community just doesn’t know right now how to best handle exception specifications.
To summarize, static checking of exception specifications is unsound and dynamic checking leaves open the problem of how to handle violations. For these reasons, along with other questions about them, I suggest that exception specifications, as we currently understand them, are a bad idea. I am glad that Ada, my favorite language, does not have them. I would encourage the Ada community to be very careful about incorporating them into a future version of the language. I’m not saying that exception specifications can’t be defined in a reasonable and useful way. I’m only saying that doing so is trickier than it at first appears and that neither Java nor C++ got it right.