10

I am new to Java and was reading its documentation on exceptions., and especially the Unchecked Exceptions — The Controversy page.

The bottom-line says:

If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

I don't understand the article. What “the controversy” is all about? Can you explain it in simple words?

gnat
  • 21,442
  • 29
  • 112
  • 288
ABcDexter
  • 209
  • 3
  • 8
  • 2
    Possible duplicate of [Checked vs Unchecked vs No Exception... A best practice of contrary beliefs](http://programmers.stackexchange.com/questions/80318/checked-vs-unchecked-vs-no-exception-a-best-practice-of-contrary-beliefs) – gnat Jul 20 '16 at 12:07
  • see also: [In Java, what are checked exceptions good for?](http://programmers.stackexchange.com/questions/19225/in-java-what-are-checked-exceptions-good-for) – gnat Jul 20 '16 at 12:07
  • PLease see the updated question, i don't feel this is a duplicate :) – ABcDexter Jul 20 '16 at 12:11
  • 3
    _"I tried to read it,"_ - what happened? – Useless Jul 20 '16 at 12:19
  • 2
    It is called like that because there is a lot of controversy around that topic. See also this StackOverflow question: [The case against checked exceptions](http://stackoverflow.com/questions/613954/the-case-against-checked-exceptions) which mentions a few quotes of famous/influential people – Hulk Jul 20 '16 at 12:22

2 Answers2

3

I'll give you an example first (but at the very end is the answer why the controversy).

Let's suposse you are editing a document in a Java-based document editor and after you are done you choose File->Save as... and you chose to save the document into a volume you don't have write permission on. The Editor wouldn't crash on you with an ugly stacktrace, it would simply tell you that it couldn't save the file and it would let you continue editing and/or save to another location.

In such a case it's probably a checked exception was expected, caught and acted upon to graciously recover from it.

On the other hand suposse these a division by zero or a null pointer exception caused by a programming error that rears its ugly head only in certain conditions. That could happen anywhere in the code, the RAM can be corrupted, etc. No API doc would tell you "this method would throw a division by zero if RAM is corrupted".

Checked exceptions should be part of the design and users of that API should prepare to handle them. Unchecked exceptions could happen almost everywhere and are beyond our control.

The controversy arises from programmers using unchecked exceptions (extending from RuntimeException) when they should be using checked exceptions:

  • as a shorcut not to be bothered by the compiler
  • to make their signatures look simpler
  • because they consider that checked exceptions are a dependency issue (if you throw a new checked exception in an implementing class you should modify the interface's signature) and viceversa.
Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
  • "you should modify the interface's signature" - well, you are even forced to do so by the compiler, and you'll have to handle or declare it to be thrown at each call site. – Hulk Jul 20 '16 at 12:41
  • 3
    Whether a UI application properly handles an error in a user-friendly way is based on how well the programmer wrote the code. They can write the code just fine that way with unchecked exceptions, just as someone else can improperly handle the errors with checked exceptions. The *intent* of checked exceptions is to make it easier for programmers to properly handle errors. The controversy is not what you've claimed here, but rather whether or not they actually successfully accomplish that goal of actually making error handling easier. In the view of many, they do not; they make it harder. – Servy Jul 20 '16 at 15:17
  • @Servy In what user friendly way could a UI app handle the fact of a failing RAM chip, or being left with no CPU cycles because another software malfunctioned? – Tulains Córdova Jul 20 '16 at 15:21
  • 1
    @TulainsCórdova In either of those cases the program isn't even going to *run*, so there is no exception handling being done *period*, so how you try to represent an error is irrelevant when you aren't able to ever even run any of your code when it happens. – Servy Jul 20 '16 at 15:25
  • @Servy Those situationd could happen when the UI app is already running and being used my the operator. – Tulains Córdova Jul 20 '16 at 15:26
  • @TulainsCórdova You seem to miss the core point though. The point is that an exception doesn't need to be marked as "checked" in order to be properly handled. You can throw an unchecked exception for someone writing to a file they don't have permission for and still handle that exception appropriately. An exception being unchecked doesn't mean it can't be handled. – Servy Jul 20 '16 at 15:27
  • @TulainsCórdova Yes, those situations can happen. When they do happen the code is not going to throw an exception that can be caught. The user code isn't even going to be able to run, period. They are problems that cause the program to stop executing, so how you attempt to handle those problems is reliant, because you never get to run code at all when they happen to even *attempt* to handle them. – Servy Jul 20 '16 at 15:29
  • @Servy Of course but the compiler wouldn't tell you of the probability of that exception. You will have to encounter the error (perhaps in production) to then consider catching the unchecked exception. – Tulains Córdova Jul 20 '16 at 15:30
  • 1
    @TulainsCórdova You don't necessarily have to have encountered the error to handle it, but yes, the compiler won't tell you that it could be thrown. The controversy is whether or not the compiler telling you that the exception could be thrown is actually helpful. Some think it is, some think it isn't. The question here is *what is the controversy*, and that is the answer. Your statement of what the core controversy of checked exceptions is is not it. – Servy Jul 20 '16 at 15:34
  • @Servy, checked exceptions are not any easier to handle than unchecked. The code to handle an exception looks the same regardless of whether it is "checked" or not. What is special about checked exceptions is that they are _harder to ignore_. A developer who writes a call to a function that could throw an IO exception is forced to either handle it, or to _explicitly_ pass the obligation to the next caller up the stack. Ultimately, someone _must_ write a handler for the exception, or the program will not compile. – Solomon Slow Jul 25 '16 at 20:14
  • @jameslarge Yes, I'm aware of all of that. The controversy is whether or not that creates a net benefit over not having that language feature. I'm not advocating either position here, I'm merely stating that there is controversy over that point. – Servy Jul 25 '16 at 20:17
-4

There is no controversy on that page. It's Oracle telling people to use checked exceptions.

The fake 'controversy' that they have invented here is between the language designers and the language users. The designers allowed people to throw and catch things that (in their mind) should not be thrown or caught. So they created a web page complaining about lazy developers.

ascotan
  • 93
  • 3
  • 4
    There _is_ a controversy even if that page says little about it. What's controversial is the answer to the question, "Do checked exceptions help or hinder the development of better software?" And, "If so, which exceptions should be checked, and which should be unchecked?" I'll wager that you could start a lively discussion if you got enough developers (and beer) together in a room to answer those questions. – Solomon Slow Jul 25 '16 at 20:21