About Manu PK

Manu develops software applications using Java and related technologies. Geek, Tech Blogger, open source and web enthusiast.

Why should you use Unchecked exceptions over Checked exceptions in Java

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)
The above are as told in Java Practices Page[2].
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

Reference: Why should you use Unchecked exceptions over Checked exceptions in Java from our JCG partner Manu PK at the The Object Oriented Life blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

One Response to "Why should you use Unchecked exceptions over Checked exceptions in Java"

  1. Jeff says:

    I do have a case against your xml example. One of our developer throws unchecked exception as you said when parsing xml in client app and crashes the app, this is in a case that the client is talking to a new server and the server is sending more elements and the client couldn’t handle. The bad thing is the client is released, and it crashes with the new server. So I support checked exception.

Leave a Reply


five + 3 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close