작성
·
691
0
안녕하세요! 항상 좋은 강의 감사드립니다.
@ControllerAdvice 공부하다가 궁금증이 생겨 질문 드립니다.
혹시, Controller에서 발생한 예외 말고, interceptor의 preHandle(), postHandle(), afterCompletion() 메서드 내에서 발생하는 예외도 @ControllerAdvice나 @ExceptionHandler로 잡을 수 있나요??
답변 3
1
1
0
안녕하세요 ygh ^^
제가 직접 정답을 알려드릴 수 도 있지만, 그러면 더 많은 것을 얻어가지 못합니다.
개발자는 궁금한 부분을 직접 코드로 테스트 해볼 때 가장 많이 배울 수 있습니다.
해당 부분을 코드로 직접 테스트해보시고, 그 결과를 공유해주세요. 그러면 함께 공부하는 분들께도 큰 도움이 될거에요.
그럼 테스트 해보시고 결과도 정리해서 공유 부탁드립니다.
감사합니다.
맞습니다. 영한님 :)
일단, 제가 이런 고민을 하게 된 배경부터 말씀드리겠습니다.
강의시간을 통해 스프링에서는 컨트롤러 밖으로 던져진 예외를 해결하는 방법으로, HandlerExceptionResolver라는 방법을 제공한다고 배웠습니다.
또한, 스프링에서는 기본적으로 HandlerExceptionResolver을 구현하는 3개의 ExceptionResolver가 있다고 배웠습니다. (ExceptionHandlerExceptionResolver, ResponseStatusExceptionResolver, DefaultHandlerExceptionResolver)
DispatcherServlet을 직접 까서 코드를 확인해 본 결과, 3개의 Resolver의 우선순위대로 루프를 돌려 각 Resolver 구현체를 얻어가며, 에러를 어떻게 처리할지 정하는 메커니즘으로 동작하고 있다고 이해했습니다. (우선순위가 높은 resolver에서 예외 처리가 가능하면 이후 resolver 스킵하고 루프 break)
그렇다면, Interceptor도 어쨌든 DispatcherServlet를 통해 동작하기 때문에, 컨트롤러뿐만 아니라 Interceptor의 preHandle(), postHandle(), afterCompletion() 내에서 발생하는 예외도 ExceptionHandlerExceptionResolver의 @ExceptionHandler와 @ControllerAdvice로 처리 수 있을 것이라고 생각했습니다.
그래서 저희 수업시간에 작성했던 LogInterceptor에서 다음과 같이 예외 처리를 시도해 보았습니다.
그런데, 디버깅 결과 예외를 처리할 수 있을것이라는 예상과는 달리, 제가 작성한 @ExceptionHandler 메서드에서는 preHandle(), postHandle(), afterCompletion()에서 발생한 예외를 처리하지 못했습니다.
혹시 제가 아예 잘못 생각하고 있는 걸까요...?ㅠ 아니면, 코딩 방식이 잘못된걸까요??