tags:

views:

356

answers:

1

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?

+2  A: 

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.

djna
+1 for "client doesn't need to know the technical details". I think the unique error number approach is completely unnecessary, though. All client needs to know is that "server error has occurred". Server logs should provide all the necessary info fro troubleshooting the problem.
ChssPly76
When you have lots of users and they are not always timely or precise in their error reporting, and you have a non-trivial n-tier architecture, I believe that these error numbers really do work and are far from unnecessary. The amount of work to implement is trivial.
djna
My bad. I didn't mean "unnecessary" as much as "pointless" :-) We've tried this approach and found that the actual error number made it back to us in about 0.5% of all cases; the rest of them were reported as "some kind of error" or "window popped up". But perhaps your users are better than mine - I can only envy you then :-)
ChssPly76
@djna - I am also leaning towards "the client does not need to know the technical details" idea. However, all the "best practices" info I can find suggests passing the caught exception to the thrown EJBException (e.g., Enterprise Java Beans 3.0 book - Burke, Monson-Haefel). But thinking more about it, this does not make sense. The server could possibly use all sorts of APIs that the client would never need to know about and passing those API's exceptions to the client just seems like bad practice.
Nemi
I think that the majority of EJB clients turn out to be servlets, so it's all in the server side, and hence the classpaths issues are moe tractable. That makes the standard advice more reasonable. I'm 100% sure that your analysis is right for the thick client case such as you're doing. There is no such thing as a "Best Practice", just a practice that is helpful in some situations, and with its own consequences; your situation reveals some of the consequences of passing the caught exception.
djna