스프링 예외 처리 Guide

스프링 예외 처리 Guide

초기 프로젝트를 설계를 해야하는데 예외처리를 효율적으로 관리할 수 있을까? 라는 생각이 들어 구글링을 뒤적뒤적 해보면서 찾던 중 좋을 글을 찾아 중요한 부분을 요약해보려 한다.

통일된 Error Response 객체 생성하기

• 통일한 객체를 에러 응답 객체로 사용함으로써 Front 에서 항상 같은 JSON 데이터 구조로 에러를 받을 수 있다.
• 통일된 객체를 사용함으로써 코드 유지보수성과 데이터가 어떻게 있는지 명확하고 추론하기 쉽다.

@ControllerAdvice 로 모든 예외를 핸들링 하여라

• 모든 예외를 한곳에서 처리하고 관리하기 수월하다.
• 스프링 자체에서 제공해주는 라이브러리 또는 자체적으로 설치한 라이브러리 등에서 발생하는 예외들을 @ExceptionHandler 을 통해 잡아주고 Error Response 객체를 생성하여 통일성 있게 처리해준다.
• 비즈니스 요구사항에 대한 예외일 경우 BusinessException 으로 통일성 있게 처리하는 것을 목표로 한다.

Error Code 정의하여 한 곳에서 관리하여라.

• 에러 코드는 Enum 타입으로 생성하여 한 곳에 관리하도록 한다.
• 에러 코드가 전체적으로 흩어져 있을 경우, 메세지의 중복을 방지하기 어렵고 전체적으로 관리하기 힘들어진다.

비즈니스 요구사항 예외는 Business Exception 처리

• 비즈니스 요구사항에 맞지 않는 예외를 개발자가 직접 Exception 처리하는 것을 BusinessException 처리 해야한다.
• 비지니스 예외를 위한 최상위 비즈니스 클래스 구조

• InvalidValueException : 유효하지 않은 값일 경우 던지는 예외
• EntityNotFoundException : 엔티티들을 조회하지 못할 경우
• BusinessException 상속 받아 어떠한 유형에 예외를 던질 지 구체적으로 명시할 수 있다.

컨트롤러 예외처리는 Validation을 적극적으로 활용

• 컨트롤러 단에서는 사용자에 요청에 대한 값들이 정확하지 판단하는 것이 옳고 그 요청들 정확하다면 서비스 로직으로 넘어가 비즈니스 요구사항에 적합하지 판단하는 것이 중요하다.
• 정리하자면, 사용자에 요청에 대한 예외는 컨트롤러, 비즈니스 로직 예외는 서비스 라고 생각하면 된다.
• Validation 라이브러리를 적극적으로 활용하여 검증 할 수 있다.

Try Catch 최대한 지양하되 사용한다면 구체적인 Exception 명시하기

• try - catch 문은 최대한 지양 해야한다.
• try - catch문 쓸 때 최소한 로그는 남겨나라 제발
• Checked Exception 때문에 반드시 try - catch문으로 감싸야 한다면 더 구체적인 Exception을 발생 시켜주어라.

---

정리

글을 쭉 읽어보면서 공통점을 찾았는데 한곳에서 관리하여라!!. 라는 강한 느낌이였다. 실상 그렇게 하지 않는다고 생각해보면 중구난방 있는 예외들을 어떻게 관리할 지 의문이 들기도 해서 당연히 한곳에서 관리하는게 맞다고 더욱 확신이 들었다.

---

참고
Spring Guide - 에외 처리 전략 | Popit