3 분 소요


서블릿 예외 처리

서블릿의 예외 처리 방식

  • Exception(예외)
  • response.sendError(HTTP 상태 코드, 오류 메시지)

Exception

자바 직접 실행

자바의 메인 메서드를 직접 실행하는 경우 main이라는 이름의 쓰레드가 실행된다.
실행중에 예외를 잡지 못하고 처음 실행한 main()메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료된다.

웹 애플리케이션

웹 애플리케이션은 사용자 요청별로 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다.
만약 애플리케이션에서 예외가 발생했는데, try - catch로 잡지 못하고 서블릿 밖으로 예외가 전달되면 다음과 같이 동작한다.

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

ServletExController

@Slf4j
@Controller
public class ServletExController {

    @GetMapping("/error-ex")
    public void errorEx() {
        throw new RuntimeException("예외 발생!");
    }
}

실행 결과
error1

Exception은 서버 내부에서 처리할 수 없는 오류가 발생한 것으로 생각해서 HTTP 상태코드 500을 반환한다.
아무 사이트나 호출하게 되면 404 상태코드를 반환한다.

response.sendError()

이것을 호출한다고 당장 예외가 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다.

  • response.sendError(HTTP 상태 코드)
  • response.sendError(HTTP 상태 코드, 오류 메시지)

ServletExController

@GetMapping("/error-404")
public void error404(HttpServletResponse response) throws IOException {
    response.sendError(404, "404 오류!");
}

@GetMapping("/error-500")
public void error500(HttpServletResponse response) throws IOException {
    response.sendError(500);
}

sendError 흐름

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

response.sendError()를 호출하면 response내부에는 오류가 발생했다는 상태를 저장해둔다.
서블릿 컨테이너는 클라이언트에게 응답 전에 response에 sendError()가 호출되었는지 확인 후 호출되었다면 설정한 오류 코드에 맞춰 기본 오류 페이지를 보여준다.


오류 화면 제공

서블릿은 Exception이 발생해서 서블릿 밖으로 전달되거나 response.sendError()가 호출되었을 때 각각의 상황에 맞춘 오류 처리 기능을 제공한다.

오류 페이지 등록

@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);
    }
}
  • response.sendError(404): errorPage404 호출
  • response.sendError(500): errorPage500 호출
  • RuntimeException 또는 그 자식 타입의 예외: errorPageEx 호출

오류가 발생했을 때 처리할 수 있는 컨트롤러가 필요하다(ErrorPageController)

ErrorPageController

@Slf4j
@Controller
public class ErrorPageController {

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

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

(return html은 생략..)

오류 페이지 동작 원리

WAS는 해당 예외를 처리하는 오류 페이지 정보를 확인한다.
new ErrorPage(RuntimeException.class, "/error-page/500")

RuntimeException 예외가 WAS까지 전달되면, WAS는 오류 페이지 정보를 확인한다.
RuntimeException의 오류페이지로 /error-page/500이 지정되어 있으므로 WAS는 오류 페이지를 출력하기 위해 /error-page/500를 다시 요청한다.

요청 흐름

1. WAS(여기까지 전달) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)
2. WAS(/error-page/500) 다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/error-page/500) -> View


오류 정보 추가

WAS는 오류 페이지 요청 뿐만 아니라, 오류 정보를 request의 attribute에 추가해서 넘겨준다.

request.attribute에 서버가 담아준 정보

  • 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 상태 코드


DispatcherType

오류가 발생하면 오류 페이지를 출력하기 위해 WAS 내부에서 다시 한번 호출이 발생하는데, 이때 필터, 서블릿, 인터셉터도 모두 다시 호출된다.
서버 내부에서 오류 페이지 호출을 위해 해당 필터나 인터셉트가 한번 더 호출되는 것은 매우 비효율적이다.
서블릿은 이런 문제를 해결하기 위해 DispatcherType이라는 추가 정보를 제공한다.

log.info("dispatchType={}", request.getDispatcherType())
클라이언트가 처음 요청시에는 dispatcherType=REQUEST로 나오고, 오류 발생시 dispatcherType=ERROR로 나온다.

DispatcherType

  • REQUEST: 클라이언트 요청
  • ERROR: 오류 요청

필터(DispatcherType)

WebConfig

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

filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);
두 가지 모두 넣으면 클라이언트 요청과 오류 페이지 요청에서 필터가 적용된다.
아무것도 넣지 않으면 기본 값이 DispatcherType.REQUEST이다. 즉, 클라이언트의 요청이 있는 경우에만 필터가 적용된다.

인터셉터

WebConfig

@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/**" //오류 페이지 경로
                );
    }
}

필터의 경우 DispatcherType을 통해 필요한 상황에 필터를 적용할지 선택할 수 있었지만 인터셉터는 서블릿이 제공하는 기능이 아닌 스프링이 제공하는 기능이다. 따라서, DispatcherType과 무관하게 항상 호출된다.

대신 인터셉터는 excludePathPatterns를 사용해 요청 경로에 따라서 제외하기 쉽게 되어있다.

전체 흐름 정리

/hello 정상 요청

WAS(/hello, dispatcherType=REQUEST) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러 -> View

/error-ex 오류 요청

  • 필터는 DispatcherType으로 중복 호출 제거(dispatcherType=REQEUST)
  • 인터셉터는 경로 정보로 중복 호출 제거(excludePathPatterns("/error-page/**)) 
    1. WAS(/error-ex, dispatcherType=REQUEST) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러
2. WAS(오류 받음) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외 발생)
3. WAS 오류 페이지 확인
4. WAS(/error-page/500, dispatcherType=ERROR) -> 필터(X) -> 서블릿 -> 인터셉터(X) -> 컨트롤러(/error-page/500) -> View


<출처 : 인프런 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술(김영한)>

댓글남기기

참고