ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Article:
  An Exception Handling Framework for J2EE Applications
Subject:   useful ideas
Date:   2006-02-13 03:51:31
From:   Shrik
Response to: useful ideas

What I also see is that if I just make a find and replace of BaseAppException for Exception, the design and architecture of the app stay the same


I am afraid that design and architecture will not remain same. BaseAppException explicitely deals with checked exceptions for an application. When you talk about using Exception, it's a base class for RuntimeException (unchecked exception) as well as other checked exceptions. By using the abstraction of BaseAppException we are clearly mentioning that framework will handle all checked exceptions which derive from BaseAppException. It's definitely not a contract for RuntimeExceptionS.


This way, if for example I change a File based implementation for a JDBC based implementation, the caller sees no change.


In my view you can throw checked exceptions too from data-access layer if root cause of them is recoverable. For instance if there is Unique Constraint Violation or StaleData problem while updating a record, you'd still like to show a friendly message to the end user as they are recoverable and user can try again. However important point here to note is that exception thrown shouldn't be third party dependendent. Which means that even if you are using JDBC or Hibernate as data-access implementation, exceptions thrown from the data-access interface should be independent from these implementations or in other words should not be dependent on JDBC or Hibernate. These exceptions will again be inherited from the derived class (say DBException) of BaseAppException and will be meaningful exceptions wrapping the root cause. Based on error code you get from SQLException or HibernateException, you can create your own user-friendly exceptions like UniqueConstraintViolationException or StaleDataException which will be recoverable for the application. These exceptions will defintely contain the root cause for logging purposes. If you check the exception handling in Spring framework, you will find similar concept. Only difference is that in Spring every exception is unchecked exception which is not the case for this framework.


Again I would like to remind you that the basis of creating RuntimeException is -- whether the exception in question is recoverable or not. If it's fatal and end-user can't do anything with it, it should be a RuntimeException otherwise should be a checked exeption (derived class of BaseAppException) only.