Exception specification, is it useful or not?

Question

first disclaimer: This is not to cause "language wars". I really need this (the clarification on the subject) for my report, and I just want to have valid and solid arguments.
Ok, so here is the question:
In C++ exception specification has been removed from C++11 standard as it was thought of as causing more hurt than good.
In Java on the other hand exception specification is seen as something good and helpful.
Are those two concepts (the purpose of having exception specification) different in those two languages and that's why they are seen differently by those two communities or those concepts are similar/identical?
Which one is it? Is exception specification a good thing or bad? Or is it good in Java because (and here I'd like to see some reasons) and in C++ is bad because (reasons go here).
Thank you for anyone with constructive help.

Answer 1

C++ and Java are not even remotely comparable in term of exception specifications, because they differ in term of exceptions:

• C++ uses dynamic allocation only when needed, programmers use stack allocation as much as possible (if only to avoid the issue of freeing memory)
• Java uses dynamic allocation almost all the time; for objects of user defined types, for arrays (even an array of a size known at compile time)

In C++ many functions can guarantee that no exception will be thrown, ever. I am not talking about exception specification, but about the documented and actual behavior of the function. For the case of a simple function call, it does not matter what the exception specification is, as long as there are no statement that can throw an exception.

[For functions that never throw an exception, exception specifications do matter when the calling code that needs to measure the potential of throwing an exception of a function, in order to call non throwing function in a way that would leave an object in a bad state if there was an exception in the middle. This is done with noexcept in modern C++, in old C++, this could have been done with much more verbose way (also, incompatible between libraries) with a type trait.]

[Note the compiler always had the right to look at the function body that was visible during compilation to determine whether it could throw exceptions, and optimize calling code accordingly (if at least for reducing the size of exception table). Throw specifications only help the compiler when it cannot see that the code couldn't throw.]

In C++ this "never throws" requirement can be documented, and enforced by the compiler, with an empty throw specification (either the good old throw() or the modern nothrow).

Java has no equivalent of that extremely useful guarantee. It can state that some functions do not throw some exception, which is useless for writing exception safe code.

Answer 2

The exception specification in Java and C++ are working in a very different way.

This is a very good source of information for the C++ point of view. http://www.gotw.ca/publications/mill22.htm

The main drawback of the C++ design was the fact that if you are throwing an unexpected exception it was very likely that your program will crash (see the link for the details). So, the exception specification is a constraint that it will apply too late.

Herb Sutter close the article saying:

Moral #1: Never write an exception specification.

Moral #2: Except possibly an empty one, but if I were you I’d avoid even that.

The Java exception specification framework is different, you have two types of exceptions: checked (compile time) and runtime exception (pretty much like the C++ with no exception specification).

With the checked exceptions, the compiler will force the developer to handle those, otherwise the application will not compile. This is good and useful, however the difference between runtime and checked exception is not completely clear and depends upon the developer and it can generate confusion. Also the checked exception are involving difficult decision even with simple program idioms (for example Checked exception specification and strategy pattern).

The final result, as usual with not clear language features, was a bad use of it. For example, C# designers decided to drop them.

I think, the java design is better than the C++03 for this specific topic (and I am a huge fan of C++), because it allows the developer to write better code in a more descriptive way. However, you need to spend energy (coding standard and code review) to produce consistent code within your development team.

Answer 3

Aside from anything else, I think the main difference between Java and C++ exception specifications is that in Java, the specification is part of the function type and the compiler enforces that you can't allow checked exceptions to escape your function unless they're part of the type of your function.

Therefore, Java checked exceptions provided a limited/flawed means of tracking what exceptions are thrown by what functions. C++ exception specifications provide a limited/flawed means of preventing a call to a function from throwing particular exceptions (or any exception).

Since they have different purposes, their success or failure has to be assessed separately for each. To the extent that actual programmers avoid using them, I think you can safely say they've both somewhat failed, but that's about all you could assess the same way for both. That extent is fairly high for Java and very high for C++. The beneficial uses they've had, and hence the exact degree of success in each language, are different.

Answer 4

Quite some years ago Java's checked exceptions have fallen out of favor as they, exactly as you put it, cause more harm than help. People nowadays mainly devise ways how to avoid them, usually by wrapping in RuntimeExceptions.

In Effective Java, Josh Bloch still defends the checked exception in the case of "exceptional, but expected, outcome", but the truth is, the API writer is not the one to decide which outcome is expected and which isn't. For example, even a FileNotFoundException can, in context, be an unexpected, fatal outcome.

So, at least, no public library should ever use checked exceptions.