Exception chaining is evil (because of hidden dependencies) - the solution is:

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)
throws IOException
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;

or implement the Externalizable interface and so the methods:

void writeExternal(ObjectOutput out)
throws IOException
void readExternal(ObjectInput in)
throws IOException,
ClassNotFoundException



In case you have an own hierarchy it is enough to implement the interface in the top-level exception.
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.


NEW online workshop: Web Components training (online)

Airport MUC workshops: Java EE 8, Java 9: Bootstrap, Effective, Architectures, Single Page Apps, Progressive Web Apps, HTML 5, ES 6, CSS 3 and Microservices

Podcast: airhacks.fm and newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

With HibernateException et al extending RuntimeException, it could be a little complicated to encapsulate them in your own exception unless you have some kind of centralized controller that dispatches all requests.

There is
<a href="http://blog.interface21.com/main/2006/04/09/another-reason-to-love-spring-20-interceptor-combining/">
an entry in the Spring team blog</a> where they propose to do this with an aspect.

Happy hacking :)

Posted by Ignacio Coloma on October 27, 2006 at 01:26 PM CEST #

Hi Ignacio,

In general, there is always a (use case)controller, or a central facade. In case you decorate this controller, you should be able to transform the exceptions,

thank you!

Posted by Adam Bien on November 03, 2006 at 11:19 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
Online Workshops
...the last 150 posts
...the last 10 comments
License