[Spring] 서블릿 예외 처리와 스프링 부트 예외 처리

 

서블릿 예외 처리

스프링이 아닌 순수 서블릿 컨테이너는 다음 2가지 방식으로 예외 처리를 지원한다.

- Exception(예외 던지기)

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

 

Exception(예외)

자바 직접 실행 : 자바의 main( ) 메서드를 넘어 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료

웹 애플리케이션

  : 요청별로 별도의 쓰레드가 할당되고, 실행

  : 예외가 발생했는데 예외를 잡지 못하면, WAS 까지 예외가 전달

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

  : 스프링 부트가 제공하는 기본 예외 페이지 (WhiteLable 화면)

  : server.error.whitelabel.enabled=false 으로 옵션 끄면 tomcat 이 제공하는 기본 예외 페이지

 

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

HttpServletResponse 가 제공하는 sendError 메서드는 response 내부에 오류가 발생했다는 상태를 저장한다.

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

설정한 오류 코드에 맞는 예외 페이지를 보여준다.

 

response.sendError(HTTP 상태 코드)

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

 

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

 

커스텀 에러 페이지

기본 에러 페이지 대신 커스텀 에러 페이지를 제공해보자.

 

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {

  @Override
  public void customize(ConfigurableWebServerFactory factory) {
    ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
    factory.addErrorPages(errorPage404);
  }
}

404 오류가 발생하면, 에러 페이지 정보를 찾아 /errorpage/404 컨트롤러가 호출된다.

이때, 해당 오류와 그 자식 타입의 오류를 함께 처리한다. 

 

이렇게 오류가 WAS 까지 전파되면, WAS 가 상태에 맞는 컨트롤러를 다시 호출한다.

@Controller
public class ErrorPageController {
  @RequestMapping("/error-page/404")
  public String errorPage404(HttpServletRequest request, HttpServletResponse response) {
    return "error-page/404";
  }
}

컨트롤러가 호출되면, error-page/404 뷰 템플릿을 화면에 렌더링하여 보여준다.

 

동작 흐름

컨트롤러(예외 발생) > 인터셉터 > 서블릿 > 필터 > WAS(/error-page/404 호출)

  > 필터 > 서블릿 > 인터셉터 > 컨트롤러(/error-page/404) > View

 

WAS 까지 오류가 전파되면 서버 내부에서 다시 오류 페이지를 호출한다.

이때, 클라이언트는 서버 내부에서 발생하는 일을 알지 못한다.

 

이렇게 WAS 가 오류 페이지를 요청할 때, request 에 오류 정보를 넘겨준다.

getAttribute(jakarta.servlet.error.exception) : 예외

getAttribute(jakarta.servlet.error.exception_type) : 예외 타입

getAttribute(jakarta.servlet.error.message) : 오류 메시지

getAttribute(jakarta.servlet.error.request_uri) : 클라이언트 요청 URI

getAttribute(jakarta.servlet.error.servlet_name) : 오류가 발생한 서블릿 이름

getAttribute(jakarta.servlet.error.status_code) : HTTP 상태 코드

getDispatcherType() : 요청구분

 

DispatcherType

서버 내부에서 에러 페이지를 호출할 때 필터나 인터셉터가 한번 더 호출되는 것은 비효율 적이다.

요청을 구분하여 특정 요청에 필터를 호출할 수 있다.

 

REQUEST : 클라이언트 요청

ERROR : 오류 요청

FORWARD : 다른 서블릿이나 JSP 호출할 때

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

ASYNC : 서블릿 비동기 호출

 

필터에서 사용법

filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);

이렇게 하면 클라이언트 요청과 에러 페이지 요청에서 필터가 호출된다.

 

DispatcherType.REQUEST 는 기본값으로, 생략 시 적용된다.

 

인터셉터에서 사용법

registry.excludePathPatterns("/error-page/**");

이렇게 하면 에러 페이지 경로일 때 인터셉터가 호출되지 않는다.

 

스프링 부트 에러 처리

스프링 부트는 에러 페이지를 만드는 과정 대부분을 자동으로 처리해 준다.

(WebServerCustomizer, ErrorPage, ErrorPageController 만들기 등)

 

ErrorPage 를 자동으로 등록하여 /error 라는 경로로 기본 에러 페이지를 설정하여,

예외가 발생하면 모든 오류를 /error 를 호출하도록 한다.

또한 BasicErrorController 라는 스프링 컨트롤러를 자동으로 등록하여,

ErrorPage 에서 등록한 /error 를 매핑하여 처리하는 BasicErrorController 컨트롤러를 자동으로 등록한다.

 

> 참고 <

에러 페이지를 자동으로 등록하는 역할은 ErrorMvcAutoConfiguration 클래스가 한다.

 

뷰 선택 우선순위

1. 뷰 템플릿 

  : resources/templates/error/500.html

  : resources/templates/error/5xx.html

2. 정적 리소스 (static, public)

  : resources/static/error/400.html

  : resources/static/error/4xx.html

3. 적용 대상 없을 때 뷰 이름 (error)

  : resources/templates/error.html

 

해당 경로 위치에 HTTP 상태 코드 이름의 뷰 파일을 넣어두면 된다.

이때, 4xx.html 이면 400 대 오류를 처리한다.

 

BasicErrorController

model 에 다음 정보를 담아서 뷰에 전달한다.

 

timestamp : 오류 발생 시간

status : HTTP 상태 코드

error : 에러 유형

exception : 예외 클래스

trace : 예외의 상세 스택 트레이드

message : 예외 메시지

errors : Spring 의 BindingResult 객체에서 발생한 검증 오류 정보

path : 예외가 발생한 URL 경로

 

오류 관련 내부 정보를 노출하는 것은 보안상의 문제가 있다.

따라서 BasicErrorController 에서 다음 정보를 model 에 포함할지 여부를 선택할 수 있다.

 

개발 서버

server.error.include-exception=true

server.error.include-message=on_param

server.error.include-stacktrace=on_param

server.error.include-binding-errors=on_param

 

운영 서버

server.error.include-exception=false

server.error.include-message=never

server.error.include-stacktrace=never

server.error.include-binding-errors=never

 

never : 사용하지 않음

always : 항상 사용

on_param : 파라미터가 있을 때 사용

(ex. message=&errors=&trace=)

 

on_param 은 디버그 시 문제를 확인하기 위해 개발 서버에서 사용할 수 있다. (운영 서버에서는 권장 X)

 

오류 관련 옵션

server.error.whitelabel.enabled=true : 스프링 기본 오류 페이지 사용 여부

server.error.path=/error : 글로벌 오류 페이지 경로

 

확장

ErrorController 인터페이스를 상속받아 구현하거나, BasicErrorController 를 상속받아 기능을 추가하면

에러 공통 처리 컨트롤러의 기능을 변경할 수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

 

출처 | 스프링 MVC 2(김영한) - 인프런