Question

I have some EJBs that use Hibernate to persist data to the database. I have a thick Swing client that talks to these EJBs. The client knows nothing about the database (no driver jar).

During one transaction a Hibernate ConstraintViolationException can be thrown. I catch all exceptions and wrap them in an EJBException like so:

catch(HibernateException e) {
    e.printStackTrace();
    throw new EJBException(e);
}

The problem I am getting is that when the exception is unmarshalled by the JBoss Invoker on the client side, a ClassNotFoundException is thrown (for PSQLException) since the client has no sql driver jar in the classpath.

I changed this application to always pass the caught exception to the ejbexception constructor like this so we could have a stack trace history. Now I am finding why the original developers didn’t do this.

At this point I see two options – either include the postgres driver jar with the client, or remove passing the caught exception to the EJBException constructor. I am curious if anyone has any other suggestions and also how others handle exceptions in their EJBs?

Answer 1

My take is that the client, end user, doesn’t need to know the technical details of the problem. Hence at various layer boundaries it’s quite reasonble to convert a technical exception to a general “An error of nature XYZ ocurred”.

A scheme I’ve seen used is for the server to allocate a unique error number at the point the exception is detected. It then writes diagnistics to its logs including that number. Messages reported to the client simply include the number. A support desk can then correlate the user’s report of the issue via that specific error number.