[MVC] 예외 처리 - 서블릿 예외 처리 (예외 처리 방식과, 예외 페이지 등록, 작동원리, DispatcherType)

스프링을 사용하지 않는 순수한 서블릿 컨테이너는 예외를 다음 두 가지 방식으로 처리한다.

 

1. Exception - 우리가 알고있는 그 일반적인 예외
2. response.sendError(HTTP 상태 코드, 오류 메시지)

 

 

---

 

1. Exception의 처리 방식

자바의 메인 메서드를 직접 실행하는 경우, main이라는 이름의 쓰레드가 실행된다.

만약 실행 도중에 예외를 잡지 못하고 처음 실행한 main() 메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료된다. 이건 많이들 경험해 보았을 것이다.

 

 

웹 애플리케이션의 경우 사용자 요청별로 별도의 쓰레드가 할당되고, 이는 서블릿 컨테이너 안에서 실행된다.

애플리케이션에서 예외가 발생한 경우, try catch로 잡지 못하고 서블릿 컨테이너 밖으로 예외가 전달되면 어떻게 동작할까?

WAS (여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러 (예외 발생)

 

해당 경우에는, Tomcat이 기본으로 제공하는 HTTP 상태코드 500번의 오류 화면을 띄우게 된다.

(만약 스프링 부트를 사용한다면, 스프링 부트가 기본으로 제공하는 오류 페이지가 띄워진다.)

 

Exception의 경우에는, 서버 내부에서 처리할 수 없는 오류가 발생한 것으로 생각해서 HTTP 상태코드 500을 반환하는 것이다.

 

 

---

 

2. SendError

WAS (sendError 호출 기록 확인) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러 (response.sendError())

response.sendError()를 호출하면, response 내부에는 오류가 발생했다는 상태를 저장해둔다.

그리고 서블릿 컨테이너는 client에게 응답하기 전에 response에 sendError()가 호출되었는지 확인한다.

그리고 만약 호출되었다면, 설정한 오류 코드에 맞추어 톰캣의 기본 오류 페이지를 보여준다

 

 

---

 

 

에러 페이지 커스텀하기

톰켓이나 스프링이 기본적으로 제공하는 에러 페이지 대신, 조금 더 이쁘게 예외 페이지를 꾸미고 싶다면, 커스텀 에러 페이지를 등록하는 것도 가능하다.

WebServerFactoryCustomizer<ConfigurableWebServerFactory> 를 상속받아 customize 메서드를 오버라이딩 하여 구현하면 된다.

 

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/errorpage/404");
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/errorpage/500");
        factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
    }
}

그리고 해당 요청을 처리할 컨트롤러를 등록해야 한다.

 

@Slf4j
@Controller
public class ErrorPageController {
    //RequestDispatcher 상수로 정의되어 있음
    public static final String ERROR_EXCEPTION = "javax.servlet.error.exception";
    public static final String ERROR_EXCEPTION_TYPE = "javax.servlet.error.exception_type";
    public static final String ERROR_MESSAGE = "javax.servlet.error.message";
    public static final String ERROR_REQUEST_URI = "javax.servlet.error.request_uri";
    public static final String ERROR_SERVLET_NAME = "javax.servlet.error.servlet_name";
    public static final String ERROR_STATUS_CODE = "javax.servlet.error.status_code";
    
    
    @RequestMapping("/error-page/404")
    public String errorPage404(HttpServletRequest request, HttpServletResponse
            response) {
        log.info("errorPage 404");
        printErrorInfo(request);
        return "error-page/404";
    }
    @RequestMapping("/error-page/500")
    public String errorPage500(HttpServletRequest request, HttpServletResponse
            response) {
        log.info("errorPage 500");
        printErrorInfo(request);
        return "error-page/500";
    }
    private void printErrorInfo(HttpServletRequest request) {
        log.info("ERROR_EXCEPTION: ex=",request.getAttribute(ERROR_EXCEPTION));
        log.info("ERROR_EXCEPTION_TYPE: {}",request.getAttribute(ERROR_EXCEPTION_TYPE));
        log.info("ERROR_MESSAGE: {}", request.getAttribute(ERROR_MESSAGE)); //ex의 경우 NestedServletException 스프링이 한번 감싸서 반환
        log.info("ERROR_REQUEST_URI: {}",request.getAttribute(ERROR_REQUEST_URI));
        log.info("ERROR_SERVLET_NAME: {}",request.getAttribute(ERROR_SERVLET_NAME));
        log.info("ERROR_STATUS_CODE: {}",request.getAttribute(ERROR_STATUS_CODE));
        log.info("dispatchType={}", request.getDispatcherType());
    }
}

 

 

---

 

예외 페이지 작동 원리

위에서 등록한 예외 페이지는 어떻게 작동한 것일까?

 

서블릿은 Exception혹은 response.sendError()가 호출 되었을 때, WAS까지 전파된다면 WAS는 해당 예외를 처리하는 오류 페이지 정보를 찾는다.

 

예를 들어 위의 경우에는 RuntimeException 예외가 WAS까지 전달되면, WAS는 오류 페이지 정보를 확인한다.

RuntimeException은 오류 페이지로 "/error/500"이 지정되어 있으며, WAS는 오류 페이지를 출력하기 위해 "/error-page/500"을 다시 요청한다.

 

다시 요청한다는 것이 중요하다.

전체적인 예외 발생시 요청 흐름은 다음과 같다.

1. WAS -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러   //요청이 들어온 경우
2. WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러 (예외 발생) //컨트롤러에서 예외가 발생한 경우
3. WAS "/error-page/500" -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러 ("/error-page/500")처리

 

 

---

DispatcherType

 

에러 페이지의 동작 원리에 대해 설명한 부분을 다시 살펴보자.

1. WAS -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러   //요청이 들어온 경우
2. WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러 (예외 발생) //컨트롤러에서 예외가 발생한 경우
3. WAS "/error-page/500" -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러 ("/error-page/500")처리

 

오류가 발생하면 오류 페이지를 출력하기 위해 WAS 내부에서 다시 한번 호출이 발생한다.

이때 필터와 인터셉터도 모두 다시 호출되는데, 에러 페이지를 띄우기 위해 내부에서 일어나는 호출에 대해 필터와 인터셉터를 작동시키지 않고 싶은 경우가 많을 것이다.

결국 이를 방지하기 위해서는 클라이언트로부터 발생한 정상 요청인지, 아니면 오류 페이지를 출력하기 위한 내부 요청인지 구분할 수 있어야 한다.

 

서블릿은 이런 문제를 해결하기 위해 DispatcherType이라는 추가 정보를 제공한다.

 

 

고객이 처음 요청했을 경우 DispatcherType은 REQUEST이다. 그리고 오류 페이지를 불러오기 위한 요청에서 DispatcherType은 ERROR이다.

이렇듯 DispatcherType을 통해 요청을 구분할 수 있으며, 이 외에도 아래와 같은 여러 DispatcherType이 존재한다.

 

REQUEST : 클라이언트 요청
ERROR : 오류 요청
FORWARD : 서블릿에서 다른 서블릿이나 JSP를 호출할 때
INCLUDE : 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때
ASYNC : 서블릿 비동기 호출

 

그리고 필터에 대해 DispatcherType을 적용하고 싶은 겨우, FilterRegistrationBean.setDispatcherTypes를 지정해주면 된다.

기본값은 DispatcherType.REQUEST이므로, 클라이언트의 요청이 있는 경우에만 필터가 적용된다.

 

인터셉터의 경우에는 excludePathPatterns를 사용하여, 오류 페이지 경로에 대해 인터셉터가 호출되지 않도록 하는 방법밖에 없다.

 

 

 

 

 

📔 Reference

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 - 인프런 | 강의