Spring 예외처리 - 오류페이지(404,500)

서블릿 컨테이너는 어떤 방법으로 예외를 처리하는지 배워보고 Spring에서의 예외처리 방법을 배워보자.

 Vaildator는 타임리프에서만 예외처리가 가능했었다. 스프링에서의 예외처리 방법을 알아보자.

 

 

# 서블릿 예외 처리

서블릿은 WAS에서 동작하는 자바 객체이다. 서블릿은 다음 2가지 방법으로 예외를 처리한다.

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

 

@ Java Exception

자바에서 예외처리를 하지않으면 앱의 진입점인 Main까지 전달되고, Main에서 처리를 하지 않으면 JVM으로 넘겨지며 오류 메시지를 생성하고 해당 쓰레드를 종료하게 된다.

 

그렇다면 톰캣 같은 WAS에서 실행되는 서블릿은 어떻게 예외가 처리될까?

@Slf4j
@Controller
public class ServletExController {
    @GetMapping("/error-ex")
    public void errorEx() { // 궁금하니 직접 예외를 만들어서 던져보자.
        throw new RuntimeException("예외 발생!");
    }
}

그냥 이렇게 HTTP 500 코드가 전송되버린다. (*스프링부트나 WAS에서 기본 오류페이지를 제공해주기도 한다.)

 

즉 서버 내부에서 예외를 처리하지 못한다면 WAS는 반환할 Response가 없다. 

• HTTP 500 코드와 함께 기본 오류페이지를 반환하게 된다. 
• 예외가 터진건 아니지만, 해당 URL을 처리할 컨트롤러가 없다면 HTTP 404 코드를 전송한다.

 

 

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

예외처리를 하지않고 WAS까지 던져버리는 건 좋은 방법이 아니다. 그래서 서블릿 response 객체에는 Exception 대신 사용할 수 있는 sendError() 라는 메서드가 존재한다. 

 ➡ response.senError()가 호출되면, WAS는 클라이언트 요청에 해당 오류코드와 메시지를 전송한다.

@Slf4j
@Controller
public class ServletExController {

    @GetMapping("/error-404")
    public void error404(HttpServletResponse response) throws IOException {
        response.sendError(404, "404 오류!"); // 오류코드와 메시지를 내가 지정할 수 있다.
    }
}

 

---

# 서블릿 오류 페이지 만들기

서블릿 컨테이너나 스프링부트가 제공하는 오류화면을 그대로 고객에게 전송하면 안된다. 어떤 자바 코드에서 예외가 발생했는지를 고객에게 굳이 보여줄 필요는 없다. 

Tomcat에서 자동으로 생성하는 오류페이지. 이런 페이지를 고객에게 보내줄 필요는 없다.

 

그래서 서블릿에서는 아래와 같은 방법으로 에러가 발생했을 때 다시 호출할 URL을 지정할 수 있다.

 ➡ 예를 들어 WAS에 HTTP 404 에러가 발생하면 https://myhome/error-page/404 로 다시 요청한다.
 ➡ 마치 리다이렉션처럼 동작하지만, HTTP 요청을 다시 보내는건아니다. 클라이언트는 이 사실을 모른다.

@Component
public class WebServerCustomizer
                    implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
                    
    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        // 200, 300 이렇게 숫자를 직접 써도 되지만 상수 값을 사용하는게 모든 방면에서 좋다.
        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");

        // 그 외 RuntimeException에 바인딩 되는 예외가 발생했을 때 사용할 페이지
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500");

        factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
    }
}

이 과정에서 필터와 인터셉터는 옵션으로 설정이 가능한데, 이는 조금있다가 알아보자

 

즉 위에서 만든 오류 URL 경로들을 컨트롤러에서 구현해주면 된다.

@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");
    this.printErrorInfo(request);
    return "error-page/404"; // 404.html 페이지 경로
  }

  @RequestMapping("/error-page/500")
  public String errorPage500(HttpServletRequest request, HttpServletResponse response) {
    log.info("errorPage 500");
    this.printErrorInfo(request);
    return "error-page/500"; // 500.html 페이지 경로
  }

  private void printErrorInfo(HttpServletRequest request) {
    //RequestDispatcher 에 있는 상수값으로 이렇게 request에서 에러정보를 받아올 수 있다.
    log.info("ERROR_EXCEPTION: {}", request.getAttribute(ERROR_EXCEPTION));
    log.info("ERROR_EXCEPTION_TYPE: {}", request.getAttribute(ERROR_EXCEPTION_TYPE));
    log.info("ERROR_MESSAGE: {}", request.getAttribute(ERROR_MESSAGE));
    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());
  }
}

 

---

# 오류가 생했을 때 필터, 인터셉터

1번과 2번은 DispatcherType이 다르다 (REQUEST, ERROR)

이처럼 오류가 발생하면, WAS에서는 마치 리다이렉션된 것처럼 오류페이지용 컨트롤러를 동작한다. 하지만 이 경우에도 필터와 인터셉터도 한번 더 실행되는데 이는 의미없는 불필요한 작업이다.

 

그래서 서블릿은 예외가 발생했을 때 필터에서 동작을 결정할 수 있게 DispatcherTypes라는 Enum값을 제공한다.

 

 

@필터의 DispatcherType

필터 객체에는 setDispatcherTypes( dispatcherType ) 라는 메서드가 있다.

해당 요청 타입일 때만 필터가 실행되도록 설정하는 기능으로, 기본값은 REQUEST만 등록되어있다.

➡ 그래서 사실은 오류페이지 요청에는 필터가 실행되지 않았다. 기본값은 REQUEST 하나 밖에 없어서 그렇다.

public enum DispatcherType {
 FORWARD, // RequestDispatcher.forward(request, response); 포워드 요청
 INCLUDE, // RequestDispatcher.include(request, response); 다른 서블릿의 결과를 포함
 REQUEST, // 클라이언트 호출
 ASYNC, // 서블릿 비동기 호출
 ERROR //오류
}

request.getDispatcherType( )

 

 

@ 인터셉터의 DispatcherType

인터셉터는 스프링 MVC의 DipatcherServlet이 실행 된 이후에 작동하는 스프링의 추가기능이다. 인터셉터에서도 request.DispatcherType 정보를 받아올 수는 있지만 해당 타입의 종류와 상관없이 인터셉터는 항상 호출된다.

➡ 하지만 걱정마라. 인터셉터에는 excludePathPatterns(...)를 추가해서 작동하지 않도록 만들 수 있다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

  @Override
  public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(new LogInterceptor())
        .order(1)
        .addPathPatterns("/**") // 사실 번거롭게 DispatcherType을 지정할 필요가 없다.
        .excludePathPatterns("/css/**", "*.ico", "/error", "/error-page/**");//오류 페이지 경로
  }
}

 

---

# 스프링 부트의 오류페이지 기능

예외처리를 만들기위해 우리는 WebServerCustomizer, ErrorPage, ErroController를 따로 만들어야 했다.

사실 번거롭게 만들지 않아도 스프링 부트는 이런 과정을 모두 기본으로 제공한다.

 

📌스프링부트의 동작

• /error/오류코드.html 을 기본 오류페이지 경로로 인식한다.

400대 오류코드의 default값 -> 4xx.html

• 스프링 부트에서 BasicErrorController라는 컨트롤러를 자동으로 등록한다.
   ➡ 기본 경로(/error/오류코드.html)를 매핑한다.
  

  

  BasicErrorController의 매핑 우선순위

  
  
• 스프링 부트의 ErrorMvcAutoConfiguration라는 클래스가 사용할 오류페이지를 WAS에 등록한다.
   ➡ 이제 서블릿 예외나 response.sendError(...)가 호출되면 모든 오류를 /error/... URL을 호출한다.

 

---

# 실제로 개발자가 할 일

이제 오류페이지를 만들려고 WebServerCustomizer를 설정하고, 컨트롤러를 만들필요가 없다.

스프링부트를 이용해서 /error/... 경로에 404.html 같은 에러페이지를 만들면 자동으로 등록된다.

• BasicErrorController 에서는 오류정보들을 모델에 담아 뷰에 전달한다. 필요하다면 아래와 같이 사용할 수 있다.

<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<head>
  <meta charset="utf-8">
</head>
<body>

<div class="container" style="max-width: 600px">
  <div class="py-5 text-center">
    <h2>500 오류 화면 스프링 부트 제공</h2>
  </div>
  
  <h1> 오류화면입니다 </h1>
  <ul>
    <li>오류 정보</li>
    <ul> <!-- 타임리프의 문자열 생성기능. 자바스크립트의 `string ${value}s`와 비슷 -->
      <li th:text="|timestamp: ${timestamp}|"></li>
      <li th:text="|path: ${path}|"></li>
      <li th:text="|status: ${status}|"></li>
      <li th:text="|message: ${message}|"></li>
      <li th:text="|error: ${error}|"></li>
      <li th:text="|exception: ${exception}|"></li>
      <li th:text="|errors: ${errors}|"></li>
      <li th:text="|trace: ${trace}|"></li>
    </ul>
    </li>
  </ul>

</div> <!-- /container -->

</body>
</html>

 

하지만 이러한 정보들을 오류페이지에 띄우면 사용자 경험&서버 보안상 좋지 않은 방법이다. 그래서 application.properties를 이용해서 BasicErrorController에서 이러한 정보를 전달하지 않도록 만들 수 있다.

exception만 전달되고 나머지는 빼고싶은경우 아래와 같이 설정하면 된다.

//application.properties
server.error.path=/error // 기본 예외 페이지 경로
server.error.whitelabel.enabled=false // 스프링 기본 오류페이지[whitelabel.html]의 사용여부

server.error.include-exception= true // exception 이름 전달여부
server.error.include-message= always // 에러 메시지를 항상 전달
server.error.include-stacktrace= on_param // [URL 요청 파라메타가 있을 때만] 전달
server.error.include-binding-errors= never // [전달안함]

• on_param은 아래와 같이 URL 요청이 있을 때만 보이게하는 기능이다.
  ➡ https://jiwondev.com/error-page?message=&trace= (message와 trace 정보 요청)

 

• 잘 사용할일은 없지만, 나만의 오류 컨트롤러가 필요하다면 BasicErrorController를 상속받거나 ErrorController 인터페이스를 이용하여 코드를 확장하여 사용할 수 있다.