EJB Exception Layer Design Feedback

Question

I am in the process of creating a EJB layer talking to EIS Tier via JCA adapter. The EJBs are all stateless. The EJBs would be used by servlets, ejbs, or jsps. The EJBs are stateless in nature. I would like to make sure the exception hierarchy I have is considered good design practice and if there are suggestions on how I may improve it. I decided to go for unchecked exception all through my design (this I don't want to change -- pretty sure about this).
So, here is how I designed my exception class. One of my goals was to keep the exception handling very simple at the client-side and not inundate customers with too many types of exceptions. I decided to go for a has-A type relationship to model much of the exceptions because I couldn’t really classify some of them to be a is-A. All exceptions thrown by my EJB layer would be contained within MyApplicationException. A getCause() will give insight into the cause at a very fine level. A getMessage() would suffice for most situations. Whereever exceptions are being thrown, the cause is being stored.
java.lang.Exception
--java.lang.RuntimeException
___ --MyBaseException
_______+----MyApplicationException (this is the container for all my exceptions)
_______+----MyConfigException
I created a exceptionhelper class that handles most of the exceptions and throws the right exception depending on the cause. For brevity sake, I am not including all code details in the sample below.
At the EIS Tier level, we have AutomationExceptions or Windows exception being thrown. These exceptions get thrown by the Windows code that is running in the EIS Tier (server). These exceptions are caught by the EJB code, then we do some processing like looking up the windows error code and producing the right message. The exception is then thrown back to the client with more information (MyApplicationException->getCause() would return AutomationException)
In the EJB code I have something like this….
try {
serverConn.connectToEISTier()
} catch (AutomatedException e) {
throw new MyApplicationException(“Custom Message.”, ExceptionHelper.handleAutomatedException(e)); }
At the EJB level
•we have create, and naming exceptions thrown either on failed lookup or something failing when creating the ejbs or there might be programming errors or there might be missing resources when EJB is trying to connect and possibly encounters data retrieval failures or Some sort of configuration error might be there in the deployment descriptor (user did soemthing wrong - wrong value for environment entry). All these are caught, and converted into runtime exception namely MyApplicationException. Where classification is deemed necessary we for e.g convert then contained exception to say configexception.
try {  
     lookup the context()
} catch(NamingException ex){
Cause = new myConfigException(“lookup failed because ….”);
Throw new MyApplicationException(cause);
At the transport level: some communication exception happened.
At the client level:
Client might be calling the apis wrongly and breaching the contract, or possibly supplied wrong credentials.
Please share feedback / thoughts.

Answer 1

There is an interesting article that discusses EJB Exception Layering:
http://www-128.ibm.com/developerworks/java/library/j-ejbexcept.html
As a rule of thumb: in every layer, create two types of exceptions that extend from the appropriate class (application exceptions and system exceptions). The next layer catches these and handles them appropriately. This way, you hide the implementation of the layers. An example where this is implemented is Spring.
To summarize, I like your idea, but I define exceptions for every layer and not put them in one hiearchy.
Regards,
Lonneke