스프링 MVC로 개발하면서 예외를 어떻게 처리할까

개인 프로젝트를 하면서 예외를 어떻게 잡아야할까 라는 생각이 많이 들었다.

 

발생할 모든 예외를 예측해서 try-catch로 잡아야하나 싶기도했다.

 

체크 예외야 IDE에서 핸들링하라고 알려주기에 어찌저찌 한다만은 언체크드 예외의 경우 다루기가 무서웠다.

 

언체크드 예외의 경우 컴파일시 안잡히니 방심하다가, 사용자가 특정 로직을 실행하다 흉악한 스택트레이스 문구가 튀어나올까 두렵기도했다.

 

토비의 스프링에서 본적이 있는데, IOException 같이 당장 해결할 수 없는 예외의 경우 언체크드 예외 (RuntimeException)으로 싸서 던지거나 싸서 던진후 다시 해당 로직을 실행하도록 하는 방향도 있다고 설명했었다.

 

여튼 명확한 기준을 세우지 못한체, 그런 생각속에 해매다 어떤분이 인프런에 질문을 올리신걸 보았는데 답변이 상당히 좋은 내용이었다!

 

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 종류를 다 잡아야하는지
애매하네요

이에 대한 답변으로

안녕하세요. ---님
스프링 프레임워크는 데이터 엑세스 계층의 구체적인 예외를 스프링 프레임워크가 추상화한 예외로 포장합니다.
그래서 어떤 예외를 잡아서 복구해야 한다면, 스프링 프레임워크 메뉴얼을 보고 사용해야 합니다.
하지만 제 경험상 대부분의 예외는 사실 신경을 크게 쓰지 않는 방향으로 설계하는게 좋습니다.(항상 그런 것은 아닙니다.)
예를 들어서 deteleById 같은 경우 생각해보면, 데이터가 없는데, deleteById가 호출될 확율은 거의 없습니다. 이게 호출되는 것 자체가 사실 로직에 문제가 있는 것이지요. 이런 경우 그냥 예외가 터지게 두고, 이 예외를 컨트롤러를 지나서 공통 예외로 처리하는게 좋습니다. 그리고 사용자에게는 문제가 있습니다. 라고 보여주고, 애플리케이션은 공통 로직으로 예외를 남기면 원인을 파악할 수 있겠지요.
반면에 애플리케이션 로직에서 deleteById가 어떤 이유에서든 데이터가 없을 때도 자주 호출되어야 한다면, 먼저 체크 로직을 태우는 것이 맞다 생각합니다.
예외는 말그대로 예외 입니다. 특히 DataAccessException를 잡아서 복구하는 경우는 정말 어쩔 수 없는 경우로 한정하는 것을 권장드립니다^^
감사합니다.

 

다른 사이트에 있는 글들도 몇번 읽은 적이 있는데, 대부분 예외가 발생하면 다시 예외를 던져 컨트롤러를 지나 공통예외로 처리하는것이 좋다는 방향이었다.

 

그렇담 ControllerAdvice 로 예외를 핸들링하면 될테니 말이다.

 

스프링 프레임워크를 공부하면서 여러 지식 파편들을 얻었지만 정작 어디에 써먹을지 몰라 해맸는데, 좋은 기회를 만나 써먹을 방도를 알아 낼 수 있어 좋았다.