This entry is inspired by pascal's comment. Hi stated "Note that it also raises the point that remote services (Session Beans)
should never throw technology-bound exceptions such as JPA ones.
One should implement his own hierarchy of exceptions and translate
them accordingly, you wouldn't want to have to deploy the JPA and other
JEE jars on the clients just to have the exception classes (ewww).", which is absolutely also my opinion.
But the decoupling can be (partially) achived in more simple way. Instead of stopping the exceptions chaining, the super-exception in your hierarchy should implement the java.io.Externalizable or Serializable in a special way. Instead of serializing everything, only the payload in String/XML format should be passed across the network boundaries. In that case it is not needed for the client to have all the libraries of the chained exceptions in the classpath.
To implement this you have either implement the "secret" methods from the java.io.Serializable interface:
private void writeObject(java.io.ObjectOutputStream out)In case you have an own hierarchy it is enough to implement the interface in the top-level exception.
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;
or implement the Externalizable interface and so the methods:
void writeExternal(ObjectOutput out)
void readExternal(ObjectInput in)
With this strategy you can pass chained exceptions to the client. But it is not always possible to catch all "technology exceptions" in a session facade.
Sometimes exceptions do occur after the completions of the transaction (e.g. optimistic collision). In that case you still need the business delegate.
Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition
airhacks.fm the podcast:
Stay in touch: airhacks.news.