Основная идея - привести DAO(JDBC) и DAO(Hibernate) к общему знаменателю, чтобы при подмене одного на другой не пришлось ничего меня в сервисе и контроллере. Для этих целей введены два новых исключения, расширяющие стандартные спринговые и более точно характеризующие ошибки.

Petro123У DAO(Хибера) нет ошибок в виде райзе в стандартной многопользовательской работе (веб проект).А теперь переведите эту фразу на русский?

Petro123,
Я не отвечаю, когда обращение идет на ты, так что закончили дискуссию

fsharp_fsharpправильно. только это не расширение. это изоляция слоев, чтобы ожидаемые DAO-исключения (конкурентный доступ, уникальность, FK и т.п.) не вылезали туда, куда им не стоитВне зависимости от того, как это назовешь стандартная трансляция исключений в spring-е не до конца продумана.

Приведу пример. Предположим ни в DAO, ни в сервисе я не перехватываю исключений (то есть не подменяю своими, а использую стандартные спринговые) и делаю обработчик в контролере. Пусть у нас есть два DAO - для JDBC и для Hibernate. Пусть есть некая таблица в БД, в которой помимо первичного ключа еще два поля (например, user_name и email) должны быть уникальны. Тогда при нарушении уникальности на поле user_name в контроллер вернутся следующие исключения (предполагается, что имена ограничений в БД имеют семантический смысл и могут быть распарсены):

DAO-JDBC:
org.springframework.dao.DuplicateKeyException: PreparedStatementCallback; SQL [insert into user_t (user_id, user_name, password, role_id, birthday, email) values (seq_id.nextval, ?, ?, ?, ?, ?)]; ORA-00001: нарушено ограничение уникальности (THIRD.USER$U$USER_NAME); nested exception is java.sql.SQLIntegrityConstraintViolationException: ORA-00001: нарушено ограничение уникальности (THIRD.USER$U$USER_NAME)

DAO-Hibernate
org.springframework.dao.DataIntegrityViolationException: could not execute statement; SQL [n/a]; constraint [THIRD.USER$U$USER_NAME]; nested exception is org.hibernate.exception.ConstraintViolationException: could not execute statement

Теперь на основе полученной информации мы хотим создать единый обработчик ошибок. Поскольку DuplicateKeyException наследует от DataIntegrityViolationException, то в обработчике надо предусмотреть обработку только DataIntegrityViolationException. Контроллеру, чтобы правильно вернуть пользователю информацию об ошибке (комментарий к полю формы ввода user_name или email), надо идентифицировать строку THIRD.USER$U$USER_NAME (для email строка будет THIRD.USER$U$EMAIL) как ограничение и разобрать ее. Для DAO-Hibernate это сделать просто - надо опуститься на уровень ниже и получить org.hibernate.exception.ConstraintViolationException, в котором заботливо предусмотрен метод getConstraintName. В DAO-Jdbc такой возможности нет и надо доставать имя ограничения прямо из сообщения. Спрашивается, что мешало создать метод (поле) getConstraintName в спринговом DataIntegrityViolationException и при реализации преобразований исключений для jdbc сделать его наполнение, раз уж эти исключения считаются стандартными?! Раз нет такой возможности, то в едином обработчике надо писать код, который бы еще проверял, а сидит ли на уровне ниже Hibernet-овское исключение или JDBC-ное (или еще какое-то), что уже криво. А с учетом того, что помимо реализации DAO может меняться и СУБД, то могут и еще какие-то проблемы всплыть.

Получается, чтобы сделать обработчик ошибок единым, надо вообще всегда брать getRootCause() и парсить исходную ошибку. И тогда от спринговых ошибок остается единственная польза - они рантаймовские. Понятно, что они поделены на группы и при анализе ошибки можно отделить DataIntegrityViolationException, например, от OptimisticLockingFailureException, но пример выше показывает, что этого недостаточно.