Spring - 서블릿 예외 처리 ( Exception )

자바에서의 예외

자바는 main 메소드를 직접 실행할 때 main 이라는 이름의 쓰레드가 실행됩니다. 이 때 실행 도중에 try catch를 통한 해당 예외 처리 조차 하지 못하고 처음 실행한 main 메소드까지 예외가 넘어온 이후,  main 메소드에서 조차도 예외를 처리하지 못하면 자바는 예외 정보를 남기고 main 쓰레드를 종료합니다.

 

웹 애플리케이션에서의 예외

웹 애플리케이션에서는 예외를 어떻게 다룰까요?

웹 애플리케이션은 "사용자 요청별"로 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행됩니다. 따라서 애플리케이션 내부 컨트롤러에서 예외가 발생했을 경우, 마찬가지로 try catch로 예외를 잡아 처리하면 문제가 없겠지만, 컨트롤러에서 예외를 처리하지 못하면 이 전 단계인 인터셉트에게 예외가 넘겨집니다. 인터셉트에서도 예외를 처리하지 못하면 서블릿 .. 서블릿에서 필터.. 필터에서 WAS 까지 전파가 됩니다.

WAS -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러 (예외발생) 
▶︎ WAS(예외 전파받음) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러 (예외전파)  

 결국 Tomcat WAS 까지 예외가 전달되게 됩니다. 그럼 WAS는 예외를 받으면 어떻게 처리할까요?

 테스트를 통해 알아보겠습니다.

참고 : 스프링이 아닌 순수 서블릿 컨테이너는 두 가지 예외 처리를 지원합니다. 
1. 직접 예외를 던지는 방식.
2. response.sendError(HTTP 상태코드, 오류 메시지) : 직접 에러를 response에 담는 방식

 

@Controller
public class ServletExController {

    @GetMapping("/error-ex")
    public void errorEx()
    {	
    	// 런타임 예외는 서버 에러 -> 500번대
        throw new RuntimeException("예외 발생");
    }

http://localhost:8080/error-ex 요청 시 

화이트라벨 오류 페이지

이 전에 자주 봤던 화이트라벨 오류 페이지가 출력됩니다.

 

WAS는 기본적으로 예외를 받았을 경우 스프링 부트가 제공하는 화이트 라벨 오류 페이지를 출력하게 되는데요. 화이트라벨 페이지가 아닌 Tomcat이 제공하는 오류 화면을 볼 수 있도록 설정하려면 application.properties에 아래 옵션을 추가해 주시면 됩니다.

  server.error.whitelabel.enabled=false

Tomcat이 제공하는 오류 화면

 

톰캣이 지원하는 오류화면이나 스프링이 지원하는 오류화면이나 클라이언트 입장에서 보았을 때 모두 친화적이진 않아요. 

하지만 서블릿은 오류화면을 커스텀할 수 있는 기능을 제공합니다.

 

커스텀 방법

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
    @Override
    public void customize(ConfigurableWebServerFactory factory) {

        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR,"/error-page/500");
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class,"/error-page/500");
        factory.addErrorPages(errorPage404,errorPage500,errorPageEx);
    }
}

1. WebServerFactoryCustomizer<ConfigurableWebServerFactory> 인터페이스 상속 받은 클래스 생성 후 컨테이너에 등록
2. customize() 메소드 오버라이딩 합니다.
3. customize 메소드 내부에 ErrorPage를 생성합니다. / ErrorPage(code, path) : code의 오류 발생 시 path 경로를 request 
4. factory에 생성한 ErrorPage를 추가해 줍니다. / factory.addErrorPage(생성한 ErrorPage .. )

@RequestMapping("/error-page/404")
public String errorPage404(HttpServletRequest request, HttpServletResponse response)
{
    log.info("errorPage 404");
    return "error-page/404";
}

컨트롤러에서는 커스터마이저에 등록한 path를 통해 error-page/404 뷰 템플릿으로 이동하도록 설정했습니다.

 

error-page/404

이렇게 되면 한 번의 요청을 통해 WAS는 두 번의 작업을 하게됩니다. 

1.  WAS("/error-ex"호출) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러 (예외발생) 
2. WAS(예외 전파받음) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러 (예외전파)  
3. ▶︎ WAS( WebServerCustomizer를 통해 예외와 매핑된 URI를 통해 어댑터(@RequestMapping("/error-page/500") 호출) -> 필터 -> 서블릿 -> 인터셉터 -> 어댑터와 매핑된 컨트롤러(errorPage404) 호출 -> 뷰 템플릿 리턴 

 

❗️당연한 이야기지만 클라이언트는 서버 내부에서 이렇게 두 번 동작하는지 알 수 없습니다. ( WAS 선에서 처리하고 최종 결과인 뷰만 클라이언트에게 리턴하기 때문에 )

 

❗️이 때 중요한 점은 3번 재호출 과정에서 request의 attribute에 오류 정보를 추가해서 넘겨준다는 점.

오류 정보는 RequestDispatcher에 상수로 정의되어 있습니다.

• javax.servlet.error.exception : 예외
• javax.servlet.error.exception_type : 예외 타입
• javax.servlet.error.message : 오류 메시지
• javax.servlet.error.request_uri : 클라이언트 요청 URI
• javax.servlet.error.servlet_name : 오류가 발생한 서블릿 이름
• javax.servlet.error.status_code : HTTP 상태 코드

@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());
}

두 번째 요청에 request에 담긴 ERROR 정보 출력

 

오류가 발생하면 오류페이지를 출력하기 위해 WAS 내부에서 호출이 추가적으로 한번 더 일어납니다. 

그렇다면 필터와, 서블릿, 인터셉터, 컨트롤러가 총 두 번 호출되는건데, 서블릿과 컨트롤러는 필수적으로 호출해야 되기 때문에 그렇다 치는데, 필터랑 인터셉터는 굳이 아래처럼 두 번 호출할 이유가 없겠죠? 설정을 통해 중복 호출을 빼보도록 하겠습니다.

서블릿 예외 처리 - 필터 중복 호출 제거 

자바 표준 스펙이 지원하는 필터의 경우에는 등록할 때 dispatcherTypes 옵션을 통해 필터를 적용할 distpatcherType을 설정할 수 있습니다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Bean
    public FilterRegistrationBean logFilter()
    {
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new LogFilter());
        filterRegistrationBean.setOrder(1);
        filterRegistrationBean.addUrlPatterns("/*");
        filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST,DispatcherType.ERROR);
        return filterRegistrationBean;
    }

default로 REQUEST만 설정되어 있습니다만, setDistPatcherTypes를 통해 직접 등록할 수 있습니다.

ERRORS를 빼고 실행하면 request에 오류정보가 담겨있는경우 필터를 적용하지 않습니다.

DispatcherType 

REQUEST : 클라이언트 요청

ERROR : 오류 요청

FORWARD : MVC에서 배웠던 서블릿에서 다른 서블릿이나 JSP를 호출할 때

• RequestDispatcher.forward(request, response);

INCLUDE : 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때

• RequestDispatcher.include(request, response);

ASYNC : 서블릿 비동기 호출

 

서블릿 예외 처리 - 인터셉터 중복 호출 제거

자바가 아닌 스프링 기술인 인터셉터의 경우에는 훨씬 간단하게 해결할 수 있습니다.

그냥 오류 페이지 경로를 excluePathPatterns를 사용해서 빼주면 됩니다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns("/css/**","/*.ico","/error","/error-page/**");
    }
}

 

서블릿에서 예외 흐름을 알아보고 필터의 setDispatcherTypes와 인터셉터의 excludePatterns 옵션으로 사용해 ERROR가 아닌 REQUEST에 대해서만 로그를 출력해 보았습니다. 

이걸 잘 활용한다면 한다면 필터와 인터셉터의 중복호출을 막을 수 있습니다!

예를 들어 로그인 인증 체크 같은 경우 이미 한번 필터나, 인터셉터에서 로그인 체크를 완료했는데 서버 내부에서 오류 페이지를 호출했을 때, 해당 필터나 인터셉트가 한번 더 호출되는 것을 필터의 setDispatcherTypes나 인터셉터의 excludePathPatterns를 이용해 막을 수 있겠습니다.

 

<참고자료>

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2/dashboard

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