Article:
  An Exception Handling Framework for J2EE Applications
Subject:   useful ideas
Date:   2006-02-13 02:38:01
From:   dario_
Response to: useful ideas

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?
Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • 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.