The debate over checked vs. unchecked exceptions goes way, way back. Some say it’s one of the best features Java included. Others say it was one of their biggest mistakes[1].
It looks like the debate is over. In this post I will try to include the links to articles and books which speaks about this topic. I am not an expert voice in this, but I will try to explain you why did I reach the this conclusion.
So, we are talking about,
Unchecked exceptions :
- represent defects in the program (bugs) - often invalid arguments passed to a non-private method. To quote from The Java Programming Language, by Gosling, Arnold, and Holmes : "Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program's logic and cannot be reasonably recovered from at run time."
- are subclasses of RuntimeException, and are usually implemented using IllegalArgumentException, NullPointerException, orIllegalStateException
- a method is not obliged to establish a policy for the unchecked exceptions thrown by its implementation (and they almost always do not do so)
Checked exceptions :
- represent invalid conditions in areas outside the immediate control of the program (invalid user input, database problems, network outages, absent files)
- are subclasses of Exception
- a method is obliged to establish a policy for all checked exceptions thrown by its implementation (either pass the checked exception further up the stack, or handle it somehow)
In many of the projects I have worked on, I have seen different ways of coding and various different strategies, code formatting, class naming styles, databases and technologies. The one thing that remained same was, Exceptions. All the projects had custom exceptions, created by extending Exception class!
I am sure that most us of know the difference between checked and unchecked exceptions, but very few thinks carefully before using them. I wanted all the details to be listed in single page so that I could convince my team to switch to Unchecked exceptions.
In his famous book, Clean code: a handbook of agile software craftsmanship[3], Robert C. Martin writes the below lines supporting Unchecked Exceptions.
The debate is over. For years Java programmers have debated over the benefits and liabilities of checked exceptions. When checked exceptions were introduced in the first version of Java, they seemed like a great idea. The signature of every method would list all of the exceptions that it could pass to its caller. Moreover, these exceptions were part of the type
of the method. Your code literally wouldn’t compile if the signature didn’t match what your code could do.
At the time, we thought that checked exceptions were a great idea; and yes, they can yield some benefit. However, it is clear now that they aren’t necessary for the production of robust software. C# doesn’t have checked exceptions, and despite valiant attempts, C++ doesn’t either. Neither do Python or Ruby. Yet it is possible to write robust software in all of these languages. Because that is the case, we have to decide—really—whether checked exceptions are worth their price.
Checked exceptions can sometimes be useful if you are writing a critical library: You must catch them. But in general application development the dependency costs outweigh the benefits
The last line is most significant, where he speaks about the general application development, Lets take an example,
If you have to read an XML file using a DOM Parser, we need to deal with some checked exceptions[5] like ParserConfigurationException, SAXException and IOException . The API developer thought that if the XML was invalid, they should notify so that the consumer of the API(ie, the application developer) can decide how to handle the situations.
Now, If You have some alternatives to proceed with the normal logic, you could do that, other wise you should catch these checked exceptions and throw and Unchecked exception. This way the method signatures will be clean also, we are stating that if the XML is invalid we are can not do much, and we are stopping the processing. Let the error handler written at the top layer take the appropriate decision on what to do.
So, all we need to do is to create out custom exception class by extending RuntimeException.
In the Java Tutorial hosted by Oracle, there is an interesting page about this debate[4], the page ends with the line, 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 have also found few article supporting this,
The Tragedy Of Checked Exceptions by Howard Lewis Ship
Exceptions are Bad by Jed Wesley-Smith
Checked exceptions I love you, but you have to go By Misko Hevery
Also, few articles on general exceptional best practices,
Guidelines Exception Handling By Vineet Reynolds
Exception-Handling Antipatterns By Tim McCune
Exceptional practices By Brian Goetz
Best Practices for Exception Handling By Gunjan Doshi