Article:		An Exception Handling Framework for J2EE Applications
Subject:		useful ideas
Date:		2006-02-12 13:52:08
From:		dario_
I deal daily with a large team of developers, each of one uses exceptions in a very personal and inconsistent way. I get all the time the same set of reasons as I read in the previous posts, and I notice in those reasons a lack of understanding of the problem (even a denial of the problem) Your ideas are a starting point to a standardization strategy I'm looking for, and I like them. But I still feel they need some improvement, as throwing BaseAppException in all the methods has some of the drawbacks of always throwing java.langn.Exception.

Showing messages 1 through 3 of 3.

• useful ideas
  2006-02-12 18:29:58  Shrik [View]
  
  
  Here is a catch. Please note that we are not throwing BaseAppException from the methods but its derived classes. In other words we are not throwing just java.lang.Exception but its so many derived classes. Definitely the throws clause just contains BaseAppException but client (ExceptionHandler) will get derived exception classes only, based on the principle of polymorphism. You need to see it from a perspective why do you use a base class in a method signature instead of its derived concrete classes in case you want to use polymorphism. You'll find an answer now on why we just throw BaseAppException.
• useful ideas
  2006-02-13 02:38:01  dario_ [View]
  
  
  I see your point and I understand code will actualy throw derived exceptions, and that by itself is good enough. 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, so the need for the BaseAppException is only to differentiate the exceptions that come from my services from the ones that come from third party services and J2SE itself. Not saying that that goal is not enough, just that I feel that all my methods are defined as if they were throwing 'Exception'. May be i'm missing something, but on the other hand, I don't think there's a perfect solution, so this one is good enough for me if I add another rule: if an exception in a method depends on the 'implementation' of the method and not on the concept of the method, wrap it in RuntimeExceptions. This way, if for example I change a File based implementation for a JDBC based implementation, the caller sees no change. After all, the caller has no idea if the implementation, so why would it need to catch the implementation dependent exception?
• useful ideas
  2006-02-13 03:51:31  Shrik [View]
  
  
  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.