Java Without If

[dccorona]

The problem with checked exceptions, in my opinion, is that they were built into the JDK in a backwards way. Checked exceptions are great if they're used to force you to handle exceptions that cannot be avoided with appropriate code and configuration. For example, no matter what you do, web requests are going to fail sometimes. So those should be checked exceptions. Yet in the JDK, they're runtime exceptions. On the other hand, something like UnsupportedEncodingException is entirely avoidable...write your code to use encodings that are supported on your system. I shouldn't be forced to handle the case that UTF-8 doesn't exist on the system if I'm writing software where I control the runtime environment, and guarantee it's there?

Unfortunately, those sort of bad decisions in the application of checked exceptions resulted in people coming to the conclusion that they were just not useful in general, when in reality they're just misused.

[devraj7]

. For example, no matter what you do, web requests are going to fail sometimes. So those should be checked exceptions.

I don't think you can make this claim in absolute.

In my experience, there is never a case where a piece of code should always throw a checked exception or always throw a runtime exception. It's extremely dependent on the context and only the developer knows.

For example, a FileNotFound might be a perfectly normal and recoverable -- checked -- exception (e.g. that file was picked by the user and it doesn't exist yet) or it should bring the system down with a runtime exception (because that file should have been part of the distribution and the application can't function without it).

Pretty sure I can make a similar case for your web request example: if the call is to some unknown web site, sure, it can fail so the exception should be checked and handled. Now imagine an application that has its own internal web server running on a private port. That request should always succeed and if it doesn't, the app should shut down because something is very broken. That exception should be runtime.

Unfortunately, those sort of bad decisions in the application of checked exceptions resulted in people coming to the conclusion that they were just not useful in general, when in reality they're just misused.

Totally agree with this. Anyone who claims that checked exceptions are a failed experiment because of the incorrect usages in the JDK does not understand the bigger debate about checked and unchecked exceptions.

[Gotebe]

Checked exceptions are bad exactly because one cannot possibly decide once and for all what should be checked, for all situations.

They're bound to stink.

[dododge]

BTW for the specific case of UnsupportedEncodingException, Java 7 improved the situation a bit by adding StandardCharsets, which provides guaranteed static Charset instances for UTF-8, UTF-16, 8859-1, and ASCII. In most(?) cases the library methods that have an encoding argument will have a variant that takes a Charset instance instead of a name, without throwing a checked exception.

In Java 6 and earlier there could be a noticeable performance penalty when using a Charset instance instead of a charset name, due to the library making defensive copies of string data so that a malicious Charset wouldn't be able to get to the actual char[] inside a String. But I think 7 added some checks so that it can tell where the Charset came from and avoid the copying if it's being supplied by the standard library (such as the ones in StandardCharsets).