Jan 11th, 2013, 03:39 PM
Difference in exception handling between PostgreSQL and HSQL
I asked this question on StackOverflow, it is probably more appropriate for this forum.
I have a weird behavior difference I'd like to understand. I have Bean Validation annotations in an entity class. I also have some code that catches them and them formats them as JSON for a REST interface -- but I think this is not impacting anything. I am using Spring and JPA Hibernate.
When I set HSQL as my database driver, I can catch the ConstrainViolationException directly after an EntityManager #persist invocation. However, when I switch the JDBC driver to Postgres #persist will throw a TransactionSystemException caused by a RollbackException then finally in the RollbackException I can get at the ConstraintViolationException. The code is identical, I only switch the driver. The #persist method is @Transactional.
Now I suppose I can workaround this by adding a catch for TransactionSystemExeption and getting the cause twice to get to the ConstraintViolationException to process, but it seems weird to me that I would need two catch clauses for identical code depending only on the driver configuration. Any thoughts or explanations?
My guess is that with HSQL, Hibernate is using code in my process to execute the bean validators BEFORE insert/commit occurs while PostgreSQL is doing either during the insert or commit. So for HSQL it just throws the ConstraintViolationException while for PostgreSQL it is a commit exception that Hibernate wraps as a RollbackException and then Spring wraps as a TransactionSystemException. This is just a guess.
In either event it is a drag to go to every unit test (testing constraints) and all my client code and add a utility method to each catch method to iterate through causes until I find a ConstraintViolationException. So (a) I'd like to better understand why this is happening and (b) is there a better approach to handling it?
Tags for this Thread