안녕하세요! 질문이 있습니다.

맞습니다. 영한님 :)

일단, 제가 이런 고민을 하게 된 배경부터 말씀드리겠습니다.

강의시간을 통해 스프링에서는 컨트롤러 밖으로 던져진 예외를 해결하는 방법으로, HandlerExceptionResolver라는 방법을 제공한다고 배웠습니다.

또한, 스프링에서는 기본적으로 HandlerExceptionResolver을 구현하는 3개의 ExceptionResolver가 있다고 배웠습니다. (ExceptionHandlerExceptionResolver, ResponseStatusExceptionResolver, DefaultHandlerExceptionResolver)

DispatcherServlet을 직접 까서 코드를 확인해 본 결과, 3개의 Resolver의 우선순위대로 루프를 돌려 각 Resolver 구현체를 얻어가며, 에러를 어떻게 처리할지 정하는 메커니즘으로 동작하고 있다고 이해했습니다. (우선순위가 높은 resolver에서 예외 처리가 가능하면 이후 resolver 스킵하고 루프 break)

그렇다면, Interceptor도 어쨌든 DispatcherServlet를 통해 동작하기 때문에, 컨트롤러뿐만 아니라 Interceptor의 preHandle(), postHandle(), afterCompletion() 내에서 발생하는 예외도 ExceptionHandlerExceptionResolver의 @ExceptionHandler와 @ControllerAdvice로 처리 수 있을 것이라고 생각했습니다.

그래서 저희 수업시간에 작성했던 LogInterceptor에서 다음과 같이 예외 처리를 시도해 보았습니다.

@Slf4j
public class LogInterceptor implements HandlerInterceptor {

    public static final String LOG_ID = "logId";

    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(IllegalArgumentException.class)
    public ErrorResult illegalExHandle(IllegalArgumentException e) {
        log.error("[exceptionHandle] ex", e);
        return new ErrorResult("BAD", e.getMessage());
    }

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse
            response, Object handler) throws Exception {
        String requestURI = request.getRequestURI();
        String uuid = UUID.randomUUID().toString();
        request.setAttribute(LOG_ID, uuid);
        log.info("REQUEST  [{}][{}][{}][{}]", uuid,
                request.getDispatcherType(), requestURI, handler);

        throw new IllegalArgumentException("preHandle에서 예외 발생!");

//        return true;
    }

    ...

그런데, 디버깅 결과 예외를 처리할 수 있을것이라는 예상과는 달리, 제가 작성한 @ExceptionHandler 메서드에서는 preHandle(), postHandle(), afterCompletion()에서 발생한 예외를 처리하지 못했습니다.

혹시 제가 아예 잘못 생각하고 있는 걸까요...?ㅠ 아니면, 코딩 방식이 잘못된걸까요??