I'm wondering if anyone out there has some advice on best practice for specifying an Exception handling strategy for a component for use in a distributed environment.
I'm torn between a desire to make debug messages as detailed (and useful) as possible on the client, verses a need to preserve encapsulation and hide implementation detail from the client.
The scenario is (Class/System names changed to protect the guilty - i.e. Me) I have an EJB session bean, coordinating actions between 2 complex underlying systems, SystemA and SystemB in this example. There are a number of data conditions that could cause a method to fail.
The interface defines a generic MyServiceException (or specific subclass to indicate a specific error condition) can be thrown.
publicvoid myMethod() throws MyServiceException ;
The current implementation of the interface returns the underlying cause Exception as a nested exception.
For instance (Class names changed to protect the guilty)
These nested Exceptions contain information useful to the client in determining what data condition caused the call to fail, but are specific exceptions thrown by the underlying systems.
The client has no access to the SystemA and SystemB classes. This causes a ClassCastException when the Exception is deserialized on the EJB client, because this class (SystemASpecificException) is not in the client classpath.
My thoughts are to introduce a specific GenericNestedException class, which is created using data (message, Exception Class name etc.) from the SystemA/BSpecificException classes, avoiding the need to serialize the actual server-side exception, whilst allowing the client code access to some info regarding the root cause.
Does anyone have any best practices from the field, that help resolve my dilemma.....
Previous Topic
