Thursday, April 30, 2015

Rethink exception handling

This is how I handle exception as a typical Web Developer in Java.
try {
   Extract 500000 $.
} catch (SQLException e ) {
  throw new RuntimeException(e);
}

You see the issue here. This is the way how developer work around the checked exception requirement. Every checked Exception 1) has to declared in called method and 2)caught and handled by calling statement. How on the earth can I as a developer know  to handle exception like SQLException at coding time?  

Checked Exception is good idea by design and is a "best-practice" enforced at language level. In reality it is a bad idea.  At 99% time, developer does not know what to do with the exception, but report it to end user.   So do we need to enforce a programming pattern that is only useful in those 1% situation? 

Moreover when it is time to report exception, we do not have enough information to do the report?    For example, 
try  {
 ....
} catch (java.lang.NumberFormatException e){
  throw new WebExeption("xxx is not a number");
}.

Here NumberFormatException is not a checked exception, but I'd like to catch it and produce a detailed report so that the end user know it is his fault. But I do not know what number the end user entered since the exception is thrown deeply from some third party library. 

Here is something I learn from my programming experience about exception handling.
  • There should no be  Checked Exception since developers in most case just re-throw caught exception.  
  • In most web application, exception handling is centralized. For example, JSF has ExceptionHandler,  JAX-RS has ExceptionWriter, jsp has error page, etc. The only exception handling is producing a detailed error report so end user knows what is wrong and how to seek help. 
  • When it comes to error report, context information is needed to produce the report.  It is unfortunately lost in current throw re-throw cycle.
  • Every Exception should have a domain(super.flexdms.com) and an error code(355) so central error handler can find out the error information easily by looking up some property file.  This is how RDBMS and HTTP designs their error report.
Here is an real example developer is really bothered by checked exception.
In the beginning, Hibernate threw all database-level exception as checked exception.  It was accepted as good programming pattern.  Right now the java/jpa/PersistenceException is a RuntimeException. Superfluous catch and re-throw is not needed.
Cheer!



1 comment:

  1. The author describes in a proper way to how to handle expectation as a Java developer. As a designer and developer, I got many important points from this post which is good for my job. Event planning app for ipad

    ReplyDelete