Exclusion specification, useful or not?

Question

first caveat: this should not cause “language wars”. I really need this (clarification on this issue) for my report, and I just want to have strong and sound arguments. So here is the question:
In C ++, an exception specification was removed from the C ++ 11 standard because it was thought to do more harm than good.
In Java, on the other hand, the specification of exceptions is seen as something good and useful. Are these two concepts (the purpose of the specification of exceptions) different in the two languages ​​and why are they visible differently by the two communities or are these concepts similar / identical?
Which one? Is the exception specification good or bad? Or is it good in Java because (and here I would like to see some reasons), but in C ++ it is bad because (the reasons go here).
Thank you for your constructive help.

Answer 1

Among other things, I think the main difference between the Java and C ++ exception specifications is that in Java the specification is part of the function type, and the compiler ensures that you do not allow checked exceptions to avoid your function if they aren’t ' part of your function.

Thus, Java's checked exceptions provided a limited / erroneous means of tracking which exceptions are thrown using which functions. C ++ exception specifications provide a limited / erroneous means of preventing a function call from throwing certain exceptions (or any exception).

Since they have different goals, their success or failure should be evaluated separately for each. To the extent that actual programmers avoid using them, I think you can safely say that they both failed, but that about everything that you could evaluate equally for both. This degree is high enough for Java and very high for C ++. The beneficial uses that they had, and therefore the exact degree of success in each language, are different.

Answer 2

The exception specification in Java and C ++ works very differently.

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

The main drawback of the C ++ design was the fact that if you throw an unexpected exception, it is very likely that your program will fail (see the link for details). Therefore, the exception specification is a limitation that will be applied too late.

Grass Sutter closes 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 structure of the Java exception specification is different, you have two types of exceptions: checked (compilation time) and runtime exception (pretty much like C ++ without an exception specification).

With checked exceptions, the compiler will force the developer to handle them, otherwise the application will not compile. This is good and useful, however, the difference between the runtime and the checked exception is not entirely clear and depends on the developer, and this can cause confusion. Also, an excluded exception is associated with a difficult decision, even with simple software idioms (for example, the Proven Exception Specification and the strategy template ).

The end result, as usual, with obscure language features, was its poor use. For example, C # developers decided to abandon them.

I think java design is better than C ++ 03 for this particular topic (and I'm a big C ++ fan) because it allows the developer to write better code in a more visual way. However, you need to spend energy (coding standard and code review) to create consistent code within your development team.

Answer 3

Just a few years ago, Java-tested exceptions were eliminated because they, as you put it, do more harm than help. Today, people mostly devise ways to avoid them, usually wrapping RuntimeException s.

In Effective Java, Josh Bloch still protects the checked exception in case of an "exceptional but expected result", but, in truth, the author of the API is not the one who decided which result is expected and which is not, For example, even FileNotFoundException in context to be unexpected, fatal.

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

Answer 4

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

• C ++ uses dynamic allocation only when necessary, programmers make the most of stack distribution (at least in order to avoid freeing memory)
• Java uses dynamic allocation almost all the time; for objects of user-defined types, for arrays (even an array of size known at compile time).

In C ++, many fundamental functions ensure that no exception is ever thrown. I'm not talking about the specification of exceptions, but about the documented and actual behavior of the function. No matter what the exception specification is, the function simply does not have an operator that can throw an exception. The caller can use this function in a context where leaving in the middle of the operation leaves the change objects in a bad, inconsistent state.

In C ++, this “never throws away” requirement can be documented and enforced by the compiler with an empty throw. Java has no equivalent to this very useful guarantee.