Women in Technology

Hear us Roar



Article:
  An Exception Handling Framework for J2EE Applications
Subject:   useful ideas
Date:   2006-02-12 18:29:58
From:   Shrik
Response to: useful ideas

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.
Main Topics Oldest First

Showing messages 1 through 1 of 1.

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