If using both jdbc and hibernate-orm (hibernate 5) in a spring project, only jdbc translates db error codes to custom DataAccessException when configuring them in sql-error-codes.xml.
Hibernate-orm only maps to the standard set of DataAccessException.
In org.springframework.orm.hibernate3.HibernateExceptionTranslator#convertHibernateAccessException the jdbcExceptionTranslator is used.
This allows with the configuration of sql-error-codes.xml to map exceptions to custom DataAccessException 's
In org.springframework.orm.hibernate5.HibernateExceptionTranslator#convertHibernateAccessException (and also the one for hibernate4) this jdbcExceptionTranslator is no longer used.
temporary solved with attached DataAccessExceptionTranslatorHibernateJpaDialect.java
this is then configured as jpaDialect on the entityManagerFactory
When using jdbcExceptionTranslator exceptions are translated to children of org.springframework.dao.DataAccessException
when using hibernates SQLExceptionConverter exceptions are translated to children of org.hibernate.JDBCException
If we want to map a (custom business) exception on the database to an exception in the java code we need 2 different Exception classes (since jdbc and hibernate map from different packages).
If we then want to map this (custom business) exception on the database to a client friendly message on the front end, we also need an ExceptionHandler that catches 2 different Exception classes, which makes it dependent on the way the database is accessed.
In HibernateJpaDialect some hibernate JDBCException are converted to spring DataAccessException (convertHibernateAccessException), and as fallback wrapped in JpaSystemException.
If using hibernates SQLExceptionConverter this would mean that the custom JDBCException would be wrapped in JpaSystemException.
This is a good point indeed: In HibernateExceptionTranslator as well as HibernateJpaDialect, a custom SQLExceptionTranslator can still be useful for translating to custom exception types... even if the standard exception types are largely covered by Hibernate's own mechanism in the meantime, and even if HibernateJpaDialect never really made use of the SQLExceptionTranslator machinery in the first place (just the Hibernate 3.x HibernateExceptionTranslator and LocalSessionFactoryBean did).
For 5.1, I've added a corresponding jdbcExceptionTranslator property, allowing you to specify a custom translator which kicks in before regular JDBCException translation. This can either be a totally custom SQLExceptionTranslator implementation which just handles your custom cases and returns null otherwise (similar to a fallbackTranslator attached to a SQLErrorCodeSQLExceptionTranslator), or one of Spring's standard translators which then overrides Hibernate's regular JDBCException translation completely.