HibernateExceptionTranslator translating to InvalidDataAccessApiUsageException when using vanilla Hibernate [SPR-14681]

[spring-projects-issues]

Koen Serneels opened SPR-14681 and commented

The new org.springframework.orm.hibernate5.HibernateExceptionTranslator uses a fallthrough in the sense that it first tries to map the exception using vanilla Hibernate (SessionFactoryUtils). If no translation could be done it tries JPA via EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible().

The latter troubles us as it is translating IllegalStateException to InvalidDataAccessApiUsageException. I'm not really sure why IllegalStateException and IllegalArgumentException get this special treatment, but ok. So now we suddenly end up with translated exceptions that weren't translated before. Since these extra translations are in context of JPA (as it is called 'convertJpaAccessExceptionIfPossible') this also makes no sense as we are not using JPA but vanilla Hibernate.

So, what is the correct way to make sure that we only get Hibernate exceptions translated? Afaic the HibernateExceptionTranslator has no options to turn off JPA translation and the LocalSessionFactoryBean extends HibernateExceptionTranslator without the option to inject another implementation. Wouldn't it make more sense to have the HibernateExceptionTranslator JPA unaware and add another translator in case JPA is actually used?

---

Affects: 4.3.2

Reference URL: https://stackoverflow.com/questions/39393116/how-to-deactivate-spring-data-exception-translation

Issue Links:

• TypeConverterSupport does not propagate custom exceptions anymore [SPR-14661] #19225 TypeConverterSupport does not propagate custom exceptions anymore
• Hibernate5 LocalSessionFactoryBean does not translate javax.persistence exceptions [SPR-14455] #19024 Hibernate5 LocalSessionFactoryBean does not translate javax.persistence exceptions

Referenced from: commits 4b44553, 34ab818

[spring-projects-issues]

Juergen Hoeller commented

The translation of IllegalStateException to InvalidDataAccessApiUsageException arguably wasn't intended in this native Hibernate case and is therefore a regression in 4.3.2. I've re-labelled this issue accordingly.

However, the general feature was intentional (see #19024): As of Hibernate 5.2, a Hibernate Session is a JPA EntityManager, and HibernateException actually extends PersistenceException now. It mostly throws HibernateException still but sometimes also plain JPA exceptions now, even when used "natively".

[spring-projects-issues]

Koen Serneels commented

Thanks Jürgen. So, to be sure, the fix will imply that both IllegalStateException and IllegalArgumentException are no longer translated?

Note: for completeness, the javadoc does mention this:
// Following the JPA specification, a persistence provider can also
// throw these two exceptions, besides PersistenceException.

[spring-projects-issues]

Juergen Hoeller commented

Yes, that's what I'm trying to balance out for this modern-day "native" use of Hibernate: just translating plain PersistenceException next to HibernateException but leaving other exceptions as-is, like before when doing native Hibernate.

[spring-projects-issues]

Juergen Hoeller commented

Are you actually relying on Hibernate-originating IllegalStateException / IllegalArgumentException to get rethrown there, or is it primarily about custom exceptions that you throw within your callbacks? Do you have some specific handling for those exceptions?

[spring-projects-issues]

Koen Serneels commented

The second: we are throwing IllegalStateException / IllegalArgumentException from repositories and are not expecting them to be wrapped/translated. While this is mostly important for our tests, it is imho arguable that such general purpose exceptions would be translated when they did not originate from JPA. So, in that case I believe the best solution is to translate if they originated from Hibernate/JPA (if that is doable) and leave them as-is otherwise

[spring-projects-issues]

Juergen Hoeller commented

It would be great if you could give the latest 4.3.3.BUILD-SNAPSHOT a try to check whether it works for you again...