Bozhidar Bozhanov

About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of Computoser and Welshare. Worked on Ericsson projects, Bulgarian e-government projects and large-scale online recruitment platforms.

Checked and unchecked exceptions in Java

Java has two types of exceptions – checked and unchecked. In short – checked are meant for cases when the developer can reasonably recover from the exception, while unchecked exceptions are programming errors that can’t be dealt with. This article explains when to use which.

But it is not that simple – checked exceptions are making the code “uglier”. They force the developer to write try/catch blocks or to rethrow the exception. But rethrowing hides another problem – some exceptions should not cross module boundaries. The most common thing to do when you are forced to catch a checked exception, which you have no idea what to do with, is to simply wrap it in a RuntimeException and rethrow it.

Actually, it might not be the most common – especially novice programmers tend to swallow exceptions, with empty catch blocks. Log & rethrow leads to doubled stacktraces sometimes, if there is some general layer for exception handling. Anyway, there are multiple bad practices here that lead to code that’s hard to debug and maintain.

Some say checked exceptions should be eliminated completely, given the verbosity, tediousness and error-proneness they introduce. C# does not have checked exceptions at all. Of course eliminating them should take into account backward compatibility.

I, however, believe the decision to have these two types of exceptions has its plus(es). It forces the developer to think that an exception is likely to happen in this situation, so he must take measures. The API declares that it will throw exceptions and the developer sees this compile-time. It enforces compile-time safety. You should not wait until the code goes to production to discover that something might fail. Javadoc? Well, a good option to say that, but I bet no one will read the javadoc until the exception actually happens.

So, how to have the “best of both worlds” ? I had a bizarre idea (explained in details here) for APIs to define two interfaces (linked through inheritance, so that only one interface is actually supported), and providing a way, through a factory, to get either an implementation whose methods throw checked exceptions, or one that wraps the checked exceptions into unchecked ones. It may be viable, it may be stupid, I can’t tell. For now it just looks strange.

But the above is a workaround at best. Then another idea came – introduce @RethrowExceptions annotation on methods. It will tell the compiler that in this method you don’t want to handle checked exceptions, but you also don’t want to declare them to be thrown. (The name of the annotation can be improved). In the simplest implementation that comes to my mind this can simply tell the compiler to surround the whole method body with try {..} catch (Exception ex) { throw new RuntimeException(ex);}. The benefits:

  • you are still warned by the compiler that the method you are using can throw an exception and you must think of handling it
  • you don’t make your code ugly by needless try/catches. And you don’t force your callers to think what to do with the exception
  • the possibility of swallowing the exception is decreased.

So in short – such an annotation would mark a method as one that is unable to handle the exception and does not want to propagate this decision to its callers.

This idea sounds less bizarre. I guess it can be implemented even now, using a compiler plug-in. Or perhaps it is already implemented in something like project lombok?

Don’t forget to share!

Reference: Checked and Unchecked Exceptions in Java from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog.

Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

Leave a Reply


eight − 8 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
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.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books