JPA/Hibernate Exception들과 예외 처리

배경

 

평소에는 JPA 관련 메서드들을 쓸때면 다음과 같이 처리했었다.

User user = userRepository.findById(id).orElseThrow(...);

 

 

orElseThrow() 는 Optional 클래스의 메서드로, 단순하게 값이 null이라면 Exception을 던져주고, null이 아니라면 반환하는 함수이다.

 

이는 단순히 결과가 null임을 처리할 수 밖에 없었다.

 

지금까지 JPA메서드에서 Exception이 던져지는 일은 없었지만,

JPA 또는 Hibernate에서 던져지는 Exception 또한 처리할 수 있어야 하겠다고 의심해 보았다.

 

Repository Exception

 

 

자주 사용하는 findById에서도 만약 id가 null일 경우 IllegalArgumentException을 던진다.

 

보통은 엔티티의 Id의 생성 전략을 명시해 두기 때문에 던져질 일은 많이 없을 것이다.

 

 

save()메서드에서도 엔티티가 null이라면 IllegalArgumentException을 던지고, 

OptimisticLockingFailureException (낙관적 로킹 예외) 도 던진다.

 

 

 

DataAccessException

 

Spring은 JPA의 예외를 의존하여 직접 사용하지 않게 할 수 있도록

대부분의 JPA 예외를 DataAccessException으로 자동 변환한다.

 

PersistenceExceptionTranslationPostProcessor가
@Repository가 적용된 클래스에 예외 변환 AOP를 적용하여 변환해준다.

 

 

이를 통해 특정 ORM에 종속되지 않는 일관된 예외 처리가 가능하다.

 

@Transactional(rollbackFor = {DataAccessException.class})
public void test() {
    // 데이터 접근 로직
}

 

트랜잭션 롤백 옵션을 통해 안전한 트랜잭션을 구성할 수 있겠다.

 

이제 Hibernate에서 사용하는 주요 예외들과 그 예시를 살펴보겠다.

 

1. EntityNotFoundException

이는 엔티티를 찾지 못한 경우이다.

EntityManager의 getReference(), refresh(), lock() 에서 던져질 수 있는 예외이다.

스프링은 JpaObjectRetrievalFailureException로 변환해준다.

 

 

try {
    User user = entityManager.getReference(User.class, 1L);
    user.setName("New Name");  // 예외 발생 가능 시점
} catch (EntityNotFoundException e) {
    log.error("사용자를 찾을 수 없습니다: ", e);
    // 에러 처리
    throw new CustomNotFoundException("요청한 사용자를 찾을 수 없습니다.", e);
}

 

2. OptimistickLockException (낙관적 로킹 예외)

낙관적 로킹을 사용했을 때, 동시에 수정을 시도하는 경우, 버전 충돌이 발생했을 때 일어날 수 있는 에러이다.

스프링은 JpaOptimisticLockingFailureException으로 변환해준다.

 

@Transactional
public void updateUser(Long userId, String newName) {
    try {
        User user = userRepository.findById(userId).orElseThrow(...);
        user.setName(newName); // 수정 시도
        userRepository.save(user);
    } catch (OptimisticLockException e) {
        log.warn("동시 수정으로 인한 충돌 발생: ", e);
        // 에러 처리
        throw new CustomConcurrencyException("다른 사용자가 동시에 수정했습니다. 다시 시도해주세요.", e);
    }
}

 

 

3. PessimisticLockException (비관적 로킹 예외)

비관적 로킹을 획득하지 못했을 때 발생한다.

스프링은 PessimisticLockingFailureException으로 변환해준다.

@Transactional
public void transferMoney(Long fromAccountId, Long toAccountId, BigDecimal amount) {
    try {
    	//출금 계좌
        Account fromAccount = accountRepository.findByIdWithLock(fromAccountId).orElseThrow(...);
        //입금 계좌
        Account toAccount = accountRepository.findByIdWithLock(toAccountId).orElseThrow();
        
        fromAccount.withdraw(amount);
        toAccount.deposit(amount);
        
        accountRepository.save(fromAccount);
        accountRepository.save(toAccount);
    } catch (PessimisticLockException e) {
        log.error("계좌 잠금 실패: ", e);
        throw new CustomLockException("계좌에 접근할 수 없습니다. 잠시 후 다시 시도해주세요.", e);
    }
}

 

 

4. ConstraintViolationException

 

DB의 제약조건을 위반했을 때 발생한다.

스프링은 DataIntegrityViolationException으로 변환해준다.

 

@Transactional
public void createUser(User user) {
    try {
        userRepository.save(user);
    } catch (ConstraintViolationException e) {
        log.error("제약조건 위반: ", e);
        Set<ConstraintViolation<?>> violations = e.getConstraintViolations();
        List<String> errorMessages = violations.stream()
            .map(ConstraintViolation::getMessage)
            .collect(Collectors.toList());
        throw new CustomValidationException("입력 데이터가 유효하지 않습니다.", errorMessages, e);
    }
}

 

 

5. QueryTimeoutException

 

쿼리 실행 시간이 Time Out 되었을 때 발생한다.

스프링은 org.springframework.dao.QueryTimeoutException으로 변환해준다.

 

@Transactional(readOnly = true)
public List<User> searchUsers(String keyword) {
    try {
        return userRepository.searchByKeyword(keyword);
    } catch (QueryTimeoutException e) {
        log.error("사용자 검색 쿼리 타임아웃: ", e);
        throw new CustomTimeoutException("쿼리 시간이 초과되었습니다.", e);
    }
}

 

 

지금까지 여러 JPA의 예외들을 보았다.

 

하지만, DataAcessException에는 다음과 같은 내용이 있다.

"이 클래스는 런타임 예외이기 때문에, 모든 오류가 치명적인 것으로 간주될 경우(일반적인 경우)에는 사용자 코드가 이 예외나 그 하위 클래스를 잡을 필요가 없습니다."

 

굳이 이 예외를 catch할 필요는 없다고 하는데.. 🤔

 

내가 정확하게 해석한건지는 모르겠지만.. 

치명적 오류일 경우에는 catch 하는 것 보다 앱을 중단시키는게 더 좋을 수도 있다 ..??

 

@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(DataAccessException.class)
    public ResponseEntity<ErrorResponse> handleDataAccessException(DataAccessException ex) {
        log.error("데이터 접근 예외 발생", ex);
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
            .body(new ErrorResponse("서버 오류가 발생했습니다."));
    }
}

 

위와 같이 Global로 Exception을 잡아서 응답을 주는 것이 가장 좋은 예시인 것 같다.

 

참고
자바 ORM 표준 JPA 프로그래밍