Cleaner Java Code with Unchecked Exceptions

Checked vs Unchecked Exceptions in Java is an already debated and documented topic. I don’t plan to discuss the details here. If you are looking for discussion on this subject I will point you to other sources:

http://stackoverflow.com/questions/6115896/java-checked-vs-unchecked-exception-explanation

http://www.quora.com/What-is-difference-between-a-checked-and-unchecked-exception

https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

This is however an example of wanting to control the exception flow of your application from an architecture level, limit the required handling by developers and provide a more consistent logging for operations and support teams.

 

Removing Checked Exceptions from your Code

 

Now, you can’t control exceptions from third party libraries or frameworks so instead you should create some exceptions for yourself. Doing this allows you to both wrap the original checked exception and then throw your new unchecked exception. Now your code will be much cleaner and you can let the exception and the true cause bubble up to either fail or return a standard response and log it. Also, you have now standardized logging and centralized the control of all your exceptions. Which allows you greater flexibility as your application grows. 

 

Additionally, by building your own exceptions your framework gains flexibility because you can control the creation and attributes of the exceptions. Now adding more attributes does increase the number of constructors but it also allows you to control the creation of your exceptions. For example, you could remove the constructor below without any parameters. This forces all developers to include a message, exceptions and/or Error Object anytime they throw an exception. This leads to better log details as your logging of the exception can include the details provided in your Error Object. Now Error object is a POJO that you own which you can mutate as your needs change.

public class MyCompaniesException extends RuntimeException {

   private ErrorObject errorObject;

   public MyCompaniesException() {
       super();
   }
   public MyCompaniesException(String message) {
       super(message);
   }
   public MyCompaniesException(Throwable cause) {
       super(cause);
   }
   public MyCompaniesException(String message, Throwable cause) {
       super(message, cause);
   }
   public MyCompaniesException(ErrorObject errorObject) {
       super();
       this.errorObject = errorObject;
   }
   public MyCompaniesException(String message, ErrorObject errorObject) {
       super(message);
       this.errorObject = errorObject;
   }
   public MyCompaniesException(String message, Throwable cause, ErrorObject errorObject) {
       super(message, cause);
       this.errorObject = errorObject;
   }
}

 

Leverage your frameworks

 

To handle these now bubbled up exceptions you can leverage the frameworks that you are already using. Just about every framework has a feature to handle the exceptions. In CXF JAX-RS there is ExceptionMapper, in CXF JAX-WS there is FaultInterceptor, Spring MVC there is Exception Handling.

 

JAX-RS – http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-Exceptionhandling

JAX-WS – http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-MappingexceptionsthrownfromCXFinterceptors

Spring MVC – https://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc

 

In each of these implementations the developer has the control to handle only specific exceptions. So if we wanted to catch all exceptions or only exceptions that extend from your companies exceptions than we could do that very easily. This allows you to be as specific (MyCompaniesException) or general (Exception) in your handling of exceptions as they leave your system.

 

The way I like to explain what happens when you let the framework do the handling is that everything in your system is now in a giant try and catch.

 

How this affects your code

 

This leads to cleaner java code as you will only have 1 try and catch at the boundary with the third party. Your framework’s exception handler will then handle the exception however you see fit. The remainder of your code becomes cleaner since the developer will only handle the exceptions when there is specific requirement. Now, the developer throws it once and knows that the framework will log and handle it. Your whole project is now built for the long term to handle exceptions.