Exception handling REST and EJB

[SurfMan]

Hi all,

What is the best practice for handling exceptions with the following frameworks:

Browser <--> REST API (JAX-RS, using RESTEasy) <--> EJB <--> JPA (using Hibernate) <--> Database (using MariaDB)

Assume I have a unique constraint on a column. When the browser posts a new record in that table, the request trickles down the stack and causes a javax.persistence.PersistenceException in my EJB, caused by Hibernate that puked with a org.hibernate.exception.ConstraintViolationExcepti on. I don't want to mix Hibernate code in my REST API service classes so I can't throw it to the calling object, nor should I push the whole stacktrace to the REST service. So what DO I tell the REST service class? I can make an EntityException, but how would I make sure the error message is what it should be? In this case, I am looking for "Duplicate entry something". But that would require me to loop over the stacktrace looking for specific SQLExceptions. That feels counter-intuitive and unnecessary.

These are the stacktrace causes:
javax.persistence.PersistenceException
org.hibernate.exception.ConstraintViolationExcepti on: could not execute statement
java.sql.SQLIntegrityConstraintViolationException: (conn=31) Duplicate entry 'AAA' for key 'accounts_ix1'
java.sql.SQLException: Duplicate entry 'AAA' for key 'accounts_ix1'

What does your Exception handling code look like when using JPA/Hibernate and (possibly) REST classes?

[benji2505]

I would try .... catch(HibernateException ...) {... and then myTransaction.rollback()}. That obviously does not resolve the accident in the primary key of your table (how did anyone manage to enter a duplicate key there in the first place???). The latter question seems to be the challenge here.

[SurfMan]

Thanks for your reply, Benji. Much appreciated.

I don't like catching vendor specific exceptions, since I want to keep this as pure JEE as I can. So I am trying to avoid catching any Hibernate*Exception. And running rollback() on a container managed transaction is not going to work. I can't even start a transaction if my container and EntityManager are calling the shots.

I agree on duplicate primary keys is questionable (one should never create id's themselves :)), but in this case, the duplicate entry key is not about primary keys, it's about violating the unique constraint that's on the table. That's entirely possible when a user enters data.

You can pull my question in a wider context about how to handle any exception in JPA→EJB→REST service.

[benji2505]

The duplicate entry issue (as with all other entry issues) could be resolved by verifying the user input at the UI.
I am not sure whether there is that one answer to handle all exceptions in the pure JPA-EJB-REST world.