-
질문 & 답변
카테고리
-
세부 분야
백엔드
-
해결 여부
미해결
JpaRepository 사용시 Exception Handling
20.06.05 10:58 작성 조회수 3.78k
1
JpaRepository를 사용하는 경우,
org.springframework.dao.DataAccessException은 RuntimeException을 상속해서
하위 Exception들은 모두 try-catch를 하지 않아도 compile상에는 문제가 없게 되버리는데요,
API doc상에서 명시적으로 어떤 DataAccessException이 발생할지 기술되지 않아서
코딩하면서 exception handing에서 실수할 여지가 많아 보입니다.
일일히 개발자 스스로 발생 가능한 exception 찾아서 handling해야할지...
좀더 효율적인 방법이 있을까요?
가령, JpaRepository의 deleteById를 사용하는 경우
존재하지 않는 Id이면 EmptyResultDataAccessException이 발생하게 되는데,
이런 경우는 existById로 한번 체크하고 그냥 deleteById를 하는게 바람직한지
아니면 그냥 deleteById를 하면서 try-catch로 발생가능한 DataAccessException 종류를 다 잡아야하는지
애매하네요.
답변을 작성해보세요.
3
김영한
지식공유자2020.06.05
안녕하세요. GPK님
스프링 프레임워크는 데이터 엑세스 계층의 구체적인 예외를 스프링 프레임워크가 추상화한 예외로 포장합니다.
그래서 어떤 예외를 잡아서 복구해야 한다면, 스프링 프레임워크 메뉴얼을 보고 사용해야 합니다.
하지만 제 경험상 대부분의 예외는 사실 신경을 크게 쓰지 않는 방향으로 설계하는게 좋습니다.(항상 그런 것은 아닙니다.)
예를 들어서 deteleById 같은 경우 생각해보면, 데이터가 없는데, deleteById가 호출될 확율은 거의 없습니다. 이게 호출되는 것 자체가 사실 로직에 문제가 있는 것이지요. 이런 경우 그냥 예외가 터지게 두고, 이 예외를 컨트롤러를 지나서 공통 예외로 처리하는게 좋습니다. 그리고 사용자에게는 문제가 있습니다. 라고 보여주고, 애플리케이션은 공통 로직으로 예외를 남기면 원인을 파악할 수 있겠지요.
반면에 애플리케이션 로직에서 deleteById가 어떤 이유에서든 데이터가 없을 때도 자주 호출되어야 한다면, 먼저 체크 로직을 태우는 것이 맞다 생각합니다.
예외는 말그대로 예외 입니다. 특히 DataAccessException를 잡아서 복구하는 경우는 정말 어쩔 수 없는 경우로 한정하는 것을 권장드립니다^^
감사합니다.
답변 1