I’m not going to try and convince you Checked Exceptions are bad. It’s controversial, and while some programmers think it should be used others thinks it should be avoided. Essentially, it’s a matter of personal taste and discipline to some extent.
In theory, Checked Exceptions are a novel idea, In practice, Checked Exceptions are usually abused or misused.
In theory, there is no difference between theory and practice. In practice, there is.
— oshai, talking about Checked Exceptions
I think Checked Exceptions are a failed experiment, at least if we examine software development trends. Modern JVM languages like Groovy, Scala and Kotlin did not adopt it from Java.
Instead of repeating the cons again, I will just highlight some arguments others already discussed.
From Oracle docs:
Here’s the bottom line guideline: 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.
Here is my bottom line: when writing code for clients (e.g. libraries), it’s hard to know in advance if they are expected to be recovered from an error, I mean it depends how they use your code and more often than not how the code is used is unknown or might change over time.
From Philipp Hauer’s Blog:
The Root of all Evil: Enforced Handling
The blog states the following reasons not to use Checked Exceptions:
- Exposing Implementation Details in the Signature
- No Appropriate Handling Possible (In some cases)
- No Recovery Possible (In some cases)
- Java 8 Lambdas and Streams
From Google Testing Blog:
…but somehow the Java developers are in love with checked exceptions. Here, I am going to “try” to convince you that checked-exceptions, even though look like a good idea at first glance, are actually not a good idea at all:…
The entire article is great, you should just read it. There is also a suggestion how to work with checked/unchecked exceptions:
“Here is my strategy to deal with checked exceptions in java:
- Always catch all checked exceptions at source and rethrow them as LogRuntimeException.
— LogRuntimeException is my runtime un-checked exception which says I don’t care just log it.
— Here I have lost Exception fidelity.
- All of my methods do not declare any exceptions
- As I discover that I need to deal with a specific exception I go back to the source where LogRuntimeException was thrown and I change it to <Specific>RuntimeException (This is rarer than you think)
— I am restoring the exception fidelity only where needed.
- Net effect is that when you come across a try-catch clause you better pay attention as interesting things are happening there.
— Very few try-catch calluses, code is much easier to read.
— Very close to 100% test coverage as there is no dead code in my catch blocks.”
That might be applied if you want a methodological way to work with Exceptions.
Hibernate docs describes why their API was changed from Checked to Unchecked Exceptions:
Until Hibernate 3.x, all exceptions thrown by Hibernate were checked exceptions, so every Hibernate API forced the developer to catch and handle exceptions. This strategy was influenced by JDBC, which also throws only checked exceptions. However, it soon became clear that this doesn’t make sense, because all exceptions thrown by Hibernate are fatal. In many cases, the best a developer can do in this situation is to clean up, display an error message, and exit the application.
Checked Exceptions: Java’s biggest mistake:
Many developers were told to catch low-level exceptions, and rethrow them again as higher (application-level) checked exceptions. This required vast numbers — 2000 per project, upwards — of non-functional “catch-throw” blocks.
If you are still using or advocating checked exceptions then I’m afraid you skill set is 5 to 10 years out of date.
… And that was written in 2010
Why spring handles only Unchecked Exceptions? here
Why C# decided not to adopt Checked Exceptions from Java:
I see two big issues with checked exceptions: scalability and versionability.
I used to be in favor of checked exceptions but recently I have begun to change my mind. Personalities like Rod Johnson (Spring Framework), Anders Hejlsberg (father of C#), Joshua Bloch (Effective Java, item 41: Avoid unnecessary use of checked exceptions) and others have made me rethink the real benefit of checked exceptions.
