4

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.

curiousguy
  • 8,038
  • 2
  • 40
  • 58
smallB
  • 16,662
  • 33
  • 107
  • 151
  • 1
    This question might be a better fit in http://programmers.stackexchange.com/ – Some programmer dude Jun 28 '12 at 11:52
  • 3
    Exception specifications are bad in C++ because: [here you go](http://www.gotw.ca/publications/mill22.htm) – Alok Save Jun 28 '12 at 11:53
  • @JoachimPileborg: unfortunately it is no longer proposed for migration :( – Matthieu M. Jun 28 '12 at 11:54
  • The answer is "yes". The Java `throws` specification is often a royal PITA, but it serves as very useful documentation and a sort of program verification tool. I have never made up my mind myself whether it's a good idea or a bad one. (It derives, BTW, from an old 1970s article on exception handling by a guy whose name I used to remember to curse who wrote more about exceptions than he knew.) – Hot Licks Jun 28 '12 at 11:54
  • #Als but does this same implies for Java? That's what I need to know. I need comparison and arguments for both languages. – smallB Jun 28 '12 at 11:55
  • You asked "Is it good or bad?" I answered "Yes". – Hot Licks Jun 28 '12 at 11:57
  • @HotLicks So the disjunction "good or bad" has a logical value of `true` :) – Marko Topolnik Jun 28 '12 at 11:58
  • @HotLicks this wasn't my question, my question is more complicated, but even if it was, "is it good or bad", the answer "yes" is meaningless. Just think about it. Are ice creams good or bad? Yes. What does it mean? – smallB Jun 28 '12 at 11:59
  • @smallB It means that they definitely are either good or bad, and not, for example, "nothing special" :) – Marko Topolnik Jun 28 '12 at 12:00
  • It means that it's good or bad on alternate days. – Hot Licks Jun 28 '12 at 12:00
  • @smallB: Your Q is of the nature, *Are ice creams god or bad for: a) Dogs b) Cats*, It doesn't make a lot of sense because cats are not dogs and vice versa. – Alok Save Jun 28 '12 at 12:00
  • 1
    @Als: and neither are are ice creams for dogs the same as the ice creams for cats. – Steve Jessop Jun 28 '12 at 12:08
  • @AlokSave C++ exception spec are actually useful. Java spec, not so much. – curiousguy Jan 28 '17 at 04:42

4 Answers4

7

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.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
  • There is a certain amount of overlap: Java guarantees that a function will not throw a checked exception if it didn't declare it. That was kind of their intended purpose: force the programmer to handle the exception instead of letting it pass by -- or declare explicitly that he is not going to handle it. Witness Java 1.0 `RuntimeException` -- no wrapper constructor. That was added later, when the checked exceptions started falling out of favor. – Marko Topolnik Jun 28 '12 at 12:22
  • 1
    @Marko: true, but Java enforces that at compile time whereas C++ enforces it at runtime. This makes a huge difference to the practical use of the two. There's another overlap, that they both serve as a form of documentation. – Steve Jessop Jun 28 '12 at 12:58
  • Yes, got it. It seems to me, though, that in C++ the aim was a compile-time guarantee, but it fell short due to the complexity of pre-existing language features. – Marko Topolnik Jun 28 '12 at 13:02
  • @Marko: possibly. After all, C++11 `noexcept` does provide some guarantees that are actively used at compile time. – Steve Jessop Jun 28 '12 at 13:05
  • @MarkoTopolnik The C++ exception specification **is** a compile time guarantee, unless you have a wrapped notion of "guarantee" and "compile time". – curiousguy Feb 27 '18 at 16:48
1

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.

Community
  • 1
  • 1
Alessandro Teruzzi
  • 3,918
  • 1
  • 27
  • 41
  • C++ exception spec allows you to specify that function will not throw at all, and this is enforced. Which is actually useful. How are Java exception spec actually useful? – curiousguy Jan 28 '17 at 04:44
  • @curiousguy using an checked exception in Java enforce (at compile time) the developer to handle the exception. Compile time constraints are always better then run time one and documentation. That's why I think they useful. Furthermore, my answer was referring to c++0x standard. Edit the answer. – Alessandro Teruzzi Jan 30 '17 at 11:34
  • What additional exception guarantees are provided by modern C++? – curiousguy Jun 18 '18 at 11:30
0

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.

Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
0

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.

curiousguy
  • 8,038
  • 2
  • 40
  • 58