본 글은 공부를 위해 망나니개발자 에서 퍼온 글입니다 .
Spring의 예외 처리 흐름
[ Spring의 예외 처리 흐름 ]
앞서 설명하였듯 다음과 같은 예외 처리기들은 스프링의 빈으로 등록되어 있고, 예외가 발생하면 순차적으로 다음의 Resolver들이 처리가능한지 판별한 후에 예외가 처리된다.
- ExceptionHandlerExceptionResolver: 에러 응답을 위한 Controller나 ControllerAdvice에 있는 ExceptionHandler를 처리함
- ResponseStatusExceptionResolver: Http 상태 코드를 지정하는 @ResponseStatus 또는 ResponseStatusException를 처리함
- DefaultHandlerExceptionResolver: 스프링 내부의 기본 예외들을 처리한다.
-
ExceptionHandlerExceptionResolver가 동작함
-
예외가 발생한 컨트롤러 안에 적합한 @ExceptionHandler가 있는지 검사함
-
컨트롤러의 @ExceptionHandler에서 처리가능하다면 처리하고, 그렇지 않으면 ControllerAdvice로 넘어감
-
ControllerAdvice안에 적합한 @ExceptionHandler가 있는지 검사하고 없으면 다음 처리기로 넘어감
-
ResponseStatusExceptionResolver가 동작함
-
@ResponseStatus가 있는지 또는 ResponseStatusException인지 검사함
-
맞으면 ServletResponse의 sendError()로 예외를 서블릿까지 전달되고, 서블릿이 BasicErrorController로 요청을 전달함
-
DefaultHandlerExceptionResolver가 동작함
-
Spring의 내부 예외인지 검사하여 맞으면 에러를 처리하고 아니면 넘어감
-
적합한 ExceptionResolver가 없으므로 예외가 서블릿까지 전달되고, 서블릿은 SpringBoot가 진행한 자동 설정에 맞게 BasicErrorController로 요청을 다시 전달함
앞서 살펴보았듯 Spring은 BasicErrorController를 구현해두었다. ExceptionHandler나 ControllerAdvice처럼 직접 에러를 반환하는 경우에는 BasicErrorController를 거치지 않지만 @ResponseStatus, ResponseStatusException 등과 같이 직접 에러 응답을 반환하지 않는 경우에는 최종적으로 BasicErrorController를 거쳐 에러가 처리된다. 클라이언트 입장에서는 이를 모르지만 내부에서는 2번 컨트롤러로 요청이 전달되는 과정이 진행된다.
참고
https://mangkyu.tistory.com/204
언체크 예외
언체크 예외(Uncheck Exception)
RuntimeException 클래스를 상속받는 예외 클래스들은 복구 가능성이 없는 예외들이므로 컴파일러가 예외처리를 강제하지 않는다. 그래서 언체크 예외라고 불리는데, 언체크 예외는 Error와 마찬가지로 에러를 처리하지 않아도 컴파일 에러가 발생하지 않는다. 즉, 런타임 예외는 예상치 못했던 상황에서 발생하는 것이 아니므로 굳이 예외 처리를 강제하지 않는다. RuntimeException에는 대표적 NullPointerException이나 IllegalArgumentException 등과 같은 것들이 있다.
언체크 예외는 신경쓰지 않고 싶은 언체크 얘외들을 모두 생략할 수 있다. 그래서 상당히 편리하지만, 컴파일러가 잡아주지 않으므로 개발자가 실수로 예외를 누락할 수 있다는 단점이 있다.
위에서 설명한 체크 예외와 언체크 예외의 차이를 아는 것은 매우 중요하다. 왜냐하면 스프링 프레임워크가 제공하는 선언적 트랜잭션(@Transactional)안에서 에러 발생 시 체크 예외는 롤백이 되지 않고, 언체크 예외는 롤백이 되기 때문이다. 이는 자바 언어와는 무관하게 프레임워크의 기능임을 반드시 알고 넘어가도록 하자. (물론 옵션을 변경할 수 있다.)
