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!



4 comments:

  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
    Replies
    1. IEEE Final Year Project centers make amazing deep learning final year projects ideas for final year students Final Year Projects for CSE to training and develop their deep learning experience and talents.

      IEEE Final Year projects Project Centers in India are consistently sought after. Final Year Students Projects take a shot at them to improve their aptitudes, while specialists like the enjoyment in interfering with innovation.

      corporate training in chennai corporate training in chennai

      corporate training companies in india corporate training companies in india

      corporate training companies in chennai corporate training companies in chennai

      I have read your blog its very attractive and impressive. I like it your blog. Digital Marketing Company in Chennai

      Delete
  2. I generally want quality content and I found that in your post. The information you have shared about developer workis in web design. beneficial and significant for us.Professional Freelance Web Designer for hire online Keep sharing these kinds of articles here. Thank you.

    ReplyDelete