Обработка данных об исключении весны

Question

Я работаю над проектом с использованием Spring Data-JPA. Мне нужно обрабатывать некоторые исключения в вызовах метода JpaRepository.

В нижеследующем коде мне нужно перехватить ошибки первичного ключа, но я не могу поймать исключение напрямую. В моем случае, когда возникает исключение такого рода, исключение UnexpectedRollbackException выбрано уровнем репозитория (JpaRepository). Мне нужно искать внутри этого объекта исключения, чтобы определить, в чем причина проблемы.

Мне интересно, есть ли более «изящный» способ достичь этого.

public Phone insert(Phone phone) throws BusinessException { 
    Phone result = null; 
    try{ 
     result = phoneRepository.save(phone); 
    } 
    catch(UnexpectedRollbackException ex){ 
     if((ex.getCause() != null && ex.getCause() instanceof RollbackException) && 
      (ex.getCause().getCause() != null && ex.getCause().getCause() instanceof PersistenceException) && 
      (ex.getCause().getCause().getCause() != null && ex.getCause().getCause().getCause() instanceof ConstraintViolationException)){ 
       throw new BusinessException("constraint violation", ex); 
     } 
    } 
    catch(Exception ex){ 
     throw new OuvidorNegocioException("unknown error", ex); 
    }  
    return result; 
} 

Спасибо!

UPDATE:

код ниже, кажется, гораздо лучше.

public Phone insert(Phone phone) throws BusinessException { 
    Phone result = null; 
    try{ 
     result = phoneRepository.save(phone); 
    } 
    catch(UnexpectedRollbackException ex){ 
     if(ex.getMostSpecificCause() instanceof SQLIntegrityConstraintViolationException){ 
       throw new BusinessException("constraint violation", ex); 
     } 
    } 
    catch(Exception ex){ 
     throw new OuvidorNegocioException("unknown error", ex); 
    }  
    return result; 
} 

Answer 1

Где бы вы ни обрабатывать исключения, у вас есть возможность смотреть в getMostSpecificCause() или getRootCause() методов UnexpectedRollbackException. Here is information об этих методах.

Answer 2

Как и с другими, которые прокомментировали ваш вопрос - я тоже думаю, что решение, которое у вас есть на вашем посту, плохое. Единственная цель абстракции репозитория - скрыть механизм сохранения, чтобы клиенты не знали об этом. В вашем случае вы ищете низкоуровневое SQL Exception, которое было намеренно абстрагировано от Spring, а также JPA.

Если вы действительно хотите обработать нарушение ограничения, то DataIntegrityViolationException является правильным, чтобы поймать. Хранилища будут обертывать специфические хранилища (MongoDB, JPA, независимо от того, что вы используете) весной DataAccessException подтипов, чтобы клиенты могли делать именно это: улавливайте исключение для каждого типа ошибки, а не за механизм персистентности.