프로그램을 개발하고 사용하는 과정에서 예상하지 못한 여러 오류 발생할 수 있다. 예외 발생 시 사용자에게 오류 페이지를 제공하는 것 또한 주요한 구현 사항 중 하나이다. 이같은 오류 페이지 관련 메커니즘을 서블릿과 스프링이 어떤 방식으로 제공하고 있는지 알아보자!
서블릿 예외 처리: 시작
스프링이 아닌 순수 서블릿 컨테이너는 예외를 어떻게 처리하는지 알아보자! (가장 하단에 위치하며 작동하는 서블릿에 대한 이해가 있어야, 그 위에 차곡차곡 쌓여서 구현된 스프링에 대한 이해도 더 깊이있게 가질 수 있다!)
서블릿은 다음 2가지 방식으로 예외 처리를 지원한다.
1.Exception(예외)
2.response.sendError(HTTP 상태 코드, 오류 메시지)
이 두가지 경우에, 서블릿은 예외의 발생을 인식한다.
1. Exception (예외)
자바 직접 실행
자바의 메인 메서드를 직접 실행하는 경우, main이라는 이름의 쓰레드가 실행된다. 실행 도중에 예외를 잡지 못하고 처음 실행한 main() 메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료된다.
기본적으로 예외는 발생 지점에서 따로 다뤄지지 않는 경우 호출부까지 상위로 거슬러 올라간다. 이를테면 repository에서 발생 시 repository를 호출한 service로, service에서도 예외가 다뤄지지 않으면 service를 호출한 controller로 거슬러 올라간다.
자바에서 main은 가장 바깥에 위치하는 메서드인데, main에서 조차 예외가 다뤄지지 않으면, 예외 정보를 남기고 해당 쓰레드가 종료되는 것이다.
웹 애플리케이션
웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 애플리케이션에서 예외가 발생했는데, try~catch로 예외가 처리되면 문제가 되지 않는다. 그런데 만약 애플리케이션에서 예외를 하지 못하고, 서블릿 밖으로 까지 예외가 전달되면 어떻게 동작할까?
WAS(😱여기까지 전파) << 필터 << 서블릿 << 인터셉터 << 컨트롤러 (😨예외발생!)
최후에는 WAS(톰캣)까지 예외가 전달된다. WAS는 예외가 올라오면 어떻게 처리할까? 이를 확인하기 위해서는 스프링부트가 제공하는 기본 예외 페이지 기능을 꺼둬야 한다.
application.properteis
server.error.whitelabel.enabled=false
ServletExController - 서블릿 예외 컨트롤러
package com.study.admin.exception.servlet;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
@Slf4j
@Controller
public class ServletExController {
@GetMapping("/error-ex")
public void errorEx() {
throw new RuntimeException("예외 발생!");
}
}-http://localhost:8080/error-ex
Exception의 경우 서버 내부에서 처리할 수 없는 오류가 발생한것으로 판단하여 HTTP 상태코드 500(서버 원인 오류)를 반환한다.
http://localhost:8080/no-page
페이지가 존재하지 않으므로 접근 오류(사용자 오류)로 판단하여 HTTP 상태코드 404를 반환했다.
response.sendErorr(HTTP 상태코드, 오류 메시지)
-
HttpServletResponse가 제공하는sendError메서드- 오류 발생 시 사용 가능.
- 메서드 호출 시점에서 예외가 당장 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가 발생했다는 것을 전달할 수 있다.
- HTTP 상태 코드와 오류 메시지 추가 가능.
-
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이 발생한다 = 500오류 (내부의 오류로 처리)
response.sendError(HTTP 상태 코드, 오류 메시지) = 내가 직접 정의한 오류!
서블릿 예외 처리: 오류 화면 제공
서블릿이 제공하는 기본 예외 처리화면은 예쁘지 않다..😟 내가 사이트 이용 중 이런 오류페이지를 마주한다면 다시 접속하지 않을 것이다... 서블릿이 제공하는 오류 화면 기능을 사용해 더 예쁜 페이지를 제공해보자!
서블릿은 Exception(예외)이 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError()가 호출되었을 때 각각 상황에 맞춘 오류 처리기능을 제공한다. 이 기능을 사용하면, 오류 별로 예쁜 처리 화면을 만들어서 고객에게 제공 가능하다!
과거에는 web.xml이라는 파일에 오류 화면을 등록했다.
<web-app>
<error-page>
<error-code>404</error-code>
<location>/error-page/404.html</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/error-page/500.html</location>
</error-page>
<error-page>
<exception-type>java.lang.RuntimeException</exception-type>
<location>/error-page/500.html</location>
</error-page>
</web-app>뭔가 나름대로 직관적이고 보기 깔끔한거 같긴 하다.
지금은 스프링 부트를 통해서 서블릿 컨테이너를 실행하므로, 스프링 부트가 제공하는 기능을 사용해 서블릿 오류 페이지를 등록하면 된다!
서블릿 오류 페이지 등록
(우리가 사용하는 톰캣과 같은) 서버에서 제공하고 있는 기본 오류페이지를 커스텀해 사용해보자! 서블릿 컨테이너가 사용하도록 제공하고 있는 기능이므로 (뭔가 코드가 너무 길고 번거롭고, 뭐가 뭔지 이해가 잘 안되더라도) 커스텀하도록 제공된 인터페이스를 구현하고 오버라이딩해서 사용해야 한다.
package com.study.admin.exception;
import org.springframework.boot.web.server.ConfigurableWebServerFactory;
import org.springframework.boot.web.server.ErrorPage;
import org.springframework.boot.web.server.WebServerFactoryCustomizer;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;
@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 호출- 500 예외는 서버 내부 오류를 의미하므로, 예외 발생 시 500오류 화면으로 처리했다.
- 오류 페이지는 예외를 다룰 때 해당 예외와 그 자식 타입의 오류를 함께 처리한다.
컨트롤러에서 발생한 오류가 다뤄지지 않으면 앞서 확인한 것처럼 (인터셉터, 서블릿, 필터를 거쳐) WAS까지 해당 에러가 던져진다. WAS(여기서 톰캣)은 던져진 에러를 확인하고, 자신만의 메커니즘으로 에러를 다루는데, 우리는 이 WAS의 기본 에러 처리과정을 위의 WebServerFactoryCustomizer 클래스로 커스터마이징 했다. 따라서, WAS는 우리의 입맛대로 지정한 에러 페이지를 제공해줄 것이다. 즉 정리하자면, 컨트롤러에서 던져진 에러가 WAS까지 던져지고, WAS가 이 에러를 처리하기위한 컨트롤러를 불러 에러 페이지를 제공해준다.
이제 특정 오류 발생 시, 특정 오류 페이지를 연결해 달라고 설정 클래스 파일을 작성했다. 이제 이 (오류와 오류 페이지를 연결할) 오류 발생 시 오류를 처리할 수 있는 컨트롤러가 필요하다. 예를들면 RuntimeException 예외 발생시 errorPageEx에서 지정한 /error-page/500이 호출되어야 한다.
에러 페이지 컨트롤러
package com.study.admin.exception.servlet;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@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";
}
}오류 관련해서 특수한 기능을 가진 컨트롤러가 아니라, 그냥 error 페이지 호출 url과 에러 페이지(View)를 연결해주는 기능만 수행한다.
오류처리 View
/template/error-page/404.html
<!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>404 오류 화면</h2>
</div>
<div>
<p>오류 화면 입니다.</p>
</div>
<hr class="my-4">
</div> <!-- /container -->
</body>
</html>/template/error-page/500.html
<!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>
<div>
<p>오류 화면 입니다.</p>
</div>
<hr class="my-4">
</div> <!-- /container -->
</body>
</html>
이제 만약 http://localhost:8080/error-ex를 검색하면 이런 (나름)예쁜 페이지를 제공할 수 있게된다!
서블릿 예외 처리: 오류 페이지 작동 원리
서블릿은 발생한 1. Exception(예외)가 서블릿 밖으로 전달되거나, 또는 2. response.sendError()가 호출되었을 때 설정된 오류 페이지를 찾는다.
1. 예외 발생 흐름
WAS(여기까지 전파) << 필터 << 서블릿 << 인터셉터 << 컨트롤러(예외발생)
2. sendError 흐름
WAS(sendError 호출 기록 확인) << 필터 << 서블릿 << 인터셉터 << 컨트롤러(response.sendError())
WAS가 예외 발생을 인지하면 오류 페이지 정보를 확인한다.
new ErrorPage(RuntimeException.class, "/error-page/500")
예를들어 RuntimeException 예외가 WAS까지 전달되면, WAS는 오류 페이지 정보를 확인하고, 오류 페이지 출력을 위해 위의 코드로 지정되어있는 /error-page/500을 다시 요청한다.
오류 페이지 요청 흐름
WAS '/error-page/500' 다시 요청 >> 필터 >> 서블릿 >> 인터셉터 >> 컨트롤러(/error-page/500) >> View
WAS가 HTTP 요청이 다시 온것처럼 처음부터 다시 요청 작업이 이루어진다. (물론 실제로 다시온 것은 아니고, 서버 내부에서 다시 온것처럼 작업이 이루어진다.)
예외 발생과 오류 페이지 요청 흐름
- WAS(여기까지 전파) << 필터 << 서블릿 << 인터셉터 << 컨트롤러(예외발생)
- WAS '/error-page/500' 다시 요청 >> 필터 >> 서블릿 >> 인터셉터 >> 컨트롤러(/error-page/500) >> View
중요한 점은 웹 브라우저(클라이언트)는 서버 내부에서 이런일이 일어나는지 전혀 모른다. 오직 서버 내부에서 오류 페이지를 찾기 위해 추가적인 호출을 한다.
정리하면 다음과 같다.
1. 예외가 발생해서 WAS까지 전파된다.
2. WAS는 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다. 이때 오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다.
필터와 인터셉터가 다시 호출되는 부분은 뒤에서 조금 더 자세히 설명된다.(조금 더 고려해야 할 부분이 있다.)
오류 정보 추가
WAS는 오류 페이지를 단순히 다시 요청만 하는 것이 아니라, 오류 정보를 request와 attribute에 추가해서 넘겨준다. 필요하면 오류 페이지에서 이렇게 전달된 오류 정보를 사용할 수 있다.
ErrorPageController - 오류 출력
package com.study.admin.exception.servlet;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@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";
private void printErrorInfo(HttpServletRequest 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("dispatcher type={}", request.getDispatcherType());
}
}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(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)
- WAS
/error-page/500다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/error-page/500) -> View
오류 발생 시 오류 페이지 출력을 위해 WAS 내부에서 다시 한번 호출이 발생한다. 이때 필터, 서블릿, 인터셉터도 모두 다시 호출된다. 로그인 인증 체크 같은 경우에는 이미 필터와 인터셉터에서 로그인 체크를 수행한 이후 오류 발생 시, 다시 로그인 체크 작업을 수행해야 한다. 이처럼 서버 내부에서 오류 페이지를 호출한다고 해서 해당 필터나 인터셉트가 다시 한번 더 호출되는 것은 매우 비효율적이다.
결국 클라이언트로부터 발생한 정상 요청인지, 아니면 오류 페이지를 출력하기 위해 내부 요청인지 구분할 수 있어야 한다. 서블릿은 이런 문제를 해결하기 위해 DispatcherType이라는 추가 정보를 제공한다.
DispatcherType
이런 경우를 위해서 필터에서 dispatcherTypes라는 옵션을 제공한다.
log.info("dispatcType = {}", request.getDispatcherType())dispatchType = ERROR
이에비해, 고객이 처음 요청하면 dispatcherType = REQUEST 이다. 이렇듯 서블릿 스펙은 실제 고객이 요청한 것인지, 서버가 내부에서 오류 페이지를 요청하는 것인지 DispatcherType으로 구분할 수 있는 방법을 제공한다.
java.serlvet.DispatcherType
public enum DispatcherType {
FORWARD,
INCLUDE,
REQUEST,
ASYNC,
ERROR
}DispatcherType
- REQUEST: 클라이언트 요청
- ERROR: 오류 요청
- FORWARD: MVC에서 배웠던 서블릿에서 다른 서블릿이나 JSP 호출 시
RequestDispatcher.forward(request, response);
- INCLUDE: 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때
RequestDispatcher.include(request, response);
- ASYNC: 서블릿 비동기 호출
필터와 DispatcherType
필터와 DispatcherType이 어떻게 사용되는지 알아보자!
LogFilter - DispatcherType 로그 추가
package com.study.admin.exception.filter;
import lombok.extern.slf4j.Slf4j;
import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import java.io.IOException;
import java.util.UUID;
@Slf4j
public class LogFilter implements Filter {
@Override
public void init(FilterConfig filterConfig) throws ServletException {
log.info("log filter init");
}
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
HttpServletRequest httpRequest = (HttpServletRequest) request;
String requestURI = httpRequest.getRequestURI();
String uuid = UUID.randomUUID().toString();
try {
log.info("REQUEST [{}][{}][{}]", uuid, request.getDispatcherType(), requestURI);
chain.doFilter(request, response);
} catch (Exception e) {
throw e;
} finally {
log.info("RESPONSE [{}][{}][{}]", uuid, request.getDispatcherType(), requestURI);
}
}
@Override
public void destroy() {
log.info("log filter destroy");
}
}로그 출력 부분에 request.getDispatcherType()이 추가되었다.
WebConfig
package com.study.admin.exception;
import com.study.admin.exception.filter.LogFilter;
import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
import javax.servlet.DispatcherType;
import javax.servlet.Filter;
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);
// 이 필터는 request, error 두가지의 경우에 호출된다.
return filterRegistrationBean;
}
}filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);
- 클라이언트 요청, 오류 페이지 요청에서 필터가 호출된다.
- 기본값:
DispatcherType.REQUEST, 클라이언트 요청 시에만 필터 적용 - 특별히 오류 요청인 경우에만 필터를 적용하고 싶다면,
DispatcehrType.ERROR도 적용 가능하다.
서블릿 예외 처리: 인터셉터
인터셉터 중복 호출 제거
LogInterceptor - DispatcherType 로그 추가
package com.study.admin.exception.interceptor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.servlet.HandlerInterceptor;
import org.springframework.web.servlet.ModelAndView;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.util.UUID;
@Slf4j
public class LogInterceptor implements HandlerInterceptor {
public static final String LOG_ID = "logId";
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse
response, Object handler) throws Exception {
String requestURI = request.getRequestURI();
String uuid = UUID.randomUUID().toString();
request.setAttribute(LOG_ID, uuid);
log.info("REQUEST [{}][{}][{}][{}]", uuid, request.getDispatcherType(), requestURI, handler);
return true;
}
@Override
public void postHandle(HttpServletRequest request, HttpServletResponse
response, Object handler, ModelAndView modelAndView) throws Exception {
log.info("postHandle [{}]", modelAndView);
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse
response, Object handler, Exception ex) throws Exception {
String requestURI = request.getRequestURI();
String logId = (String) request.getAttribute(LOG_ID);
log.info("RESPONSE [{}][{}][{}]", logId, request.getDispatcherType(), requestURI);
if (ex != null) {
log.error("afterCompletion error!!", ex);
}
}
}이전에 본 필터의 경우, DispatcherType이라는 요청의 성격에 따라 필터를 적용할지말지 선택할 수 있었다. 그러나 인터셉터는 서블릿이 아니라 스프링이 제공하는 기능이므로, DispatcherType과 무관하게 항상 호출된다. (DispatcherType으로 적용 여부를 선택할 수 없다.)
대신 인터셉터는 요청 경로(url)에 따라서 인터셉터 적용 유무를 추가하거나 제외할 수 있는 excludePathPatters 기능을 제공하므로, 이 설정을 이용하여 오류 페이지 경로를 인터셉터 적용 경로에서 빼주면 된다!
WebConfig
package com.study.admin.exception;
import com.study.admin.exception.filter.LogFilter;
import com.study.admin.exception.interceptor.LogInterceptor;
import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
import javax.servlet.DispatcherType;
import javax.servlet.Filter;
public class WebConfig implements WebMvcConfigurer {
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new LogInterceptor())
.order(1)
.addPathPatterns("/**")
.excludePathPatterns("/css/**", "*.ico", "/error", "/error-page/**");
// 오류 페이지 경로에도 인터셉터를 적용하지 않는다.
}
// @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;
}
}- 인터셉터와 중복 처리되지 않도록 logFilter()의 @Bean에 주석을 달아둔다.
- 만약
/error-page/**설정을 제거하면,error-page/500과 같은 내부 호출의 경우에도 인터셉터가 호출된다.
전체 흐름 정리
/hello 정상 요청
WAS(/hello, dispatchType=REQUEST) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러 -> View
/error-ex 오류 요청 (중복 제거)
- 필터는
DispatchType으로 중복 호출 제거(dispatchType=REQUEST) - 인터셉터는 경로 정보로 중복 호출 제거(
excludPathPattersn("/error-page/**")
- WAS(/error-ex, dispatchType=REQUEST) >> 필터 >> 서블릿 >> 인터셉터 >> 컨트롤러
- WAS (여기까지 전파) << 필터 << 서블릿 << 인터셉터 << 컨트롤러(예외발생)
- WAS 오류 페이지 확인
- WAS(/error-page/500, dispatchType=ERROR) >> 필터(x) >> 서블릿 >> 인터셉터(x) >> 컨트롤러(/error-page/500) >> View
스프링부트: 오류페이지1
지금까지 예외 처리 페이지를 위해 우리가 구현해온 과정은 다음과 같다.
WebServerCustomizer생성- 예외 종류에 따라
ErrorPage추가 - 예외 처리용 컨트롤러
ErrorPageController생성...
이 같은 과정이 꽤 번거롭고 구현해야 할 사항들이 많기 때문에, 스프링에서 기본으로 제공하고 있는 오류 처리 과정을 살펴보고, 이를 활용해 오류 페이지를 처리해보자!
스프링 부트의 기본 오류 처리 과정
ErrorPage를 자동으로 등록한다. 이때,/error라는 경로로 기본 오류 페이지를 설정한다.new ErrorPage("/error"), 상태코드와 예외를 설정하지 않으면 기본 오류 페이지로 사용된다.- 서블릿 밖으로 예외가 발생하거나,
response.sendError(...)가 호출되면 모든 오류는/error를 호출하게 된다.
별도로 오류 페이지 관련 설정이 없는 경우, 스프링이 기본적으로/error라는 경로로 오류 페이지를 설정해둔다.
BasicErrorController라는 스프링 컨트롤러를 자동으로 등록한다.ErrorPage에서 등록한/error를 매핑해서 처리하는 컨트롤러다.
에러 url과 view를 연결하는 컨트롤러로, 스프링은 BasicErrorController를 제공하고 있다.
참고
ErrorMvcAutoConfiguration이라는 클래스가 오류 페이지를 자동으로 등록하는 역할을 한다. (이건 진짜 참고만 하면 된다.)
주의
스프링 부트가 제공하는 기본 오류 메커니즘을 사용하기 위해선, WebServerCustomizer에 설정한@Component를 주석 처리해야 한다.
BasicErrorController
이렇게 다른 설정이 없으면 /error로 연결되도록 컨트롤러가 구현되어 있다. (우리는 앞서 에러를 전달할 url(/error)을 지정하고, 이 url과 view를 매핑할 컨트롤러를 직접 만들었다.) 스프링이 기본 제공하는 BasicErrorController에는 우리가 앞서 구현한 url <-> 컨트롤러 기능이 구현되어 있다!
개발자는 오류 페이지만 등록!
BasicErrorController는 기본적인 로직이 모두 개발되어 있으므로, 개발자는 오류 페이지 화면만 BasicErrorController가 제공하는 룰과 우선순위에 따라 등록하면 된다! (정적 HTML이면) 정적 리소스, (뷰 템플릿 활용해 동적 오류 화면을 만들고 싶은 경우) 뷰 템플릿 경로에 오류 페이지 파일을 만들어서 넣어두기만 하면 된다!
뷰 선택 우선순위
BasicErrorController의 처리 우선순서
- 뷰 템플릿
resources/templates/error/500.htmlresources/templates/error/5xx.html- 자세한 url이 우선순위가 높다!
- 정적 리소스(static, public)
resources/static/error/400.htmlresources/static/error/404.htmlresources/static/error/4xx.html
- 적용 대상이 없을 때 뷰 이름(error)
resources/templates/error.html
해당 경로에 HTTP 상태 코드 이름의 뷰 파일을 넣어두면 된다.
뷰 템플릿이 정적 리소스보다 우선 순위가 높고, 404, 500처럼 구체적인 것이 5xx처럼 덜 구체적인 것보다 우선순위가 높다. 5xx, 4xx라고 파일명을 지정해두면 500대, 400대 오류를 처리해준다.
너무 좋다.너무 편리하다. 스프링 최고...
오류 뷰 템플릿 추가
resources/templates/error/4xx.html
<!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>4xx 오류 화면 스프링 부트 제공</h2>
</div>
<div>
<p>오류 화면 입니다.</p>
</div>
<hr class="my-4">
</div> <!-- /container -->
</body>
</html>스프링부트: 오류페이지2
BasicErrorController에서 오류와 관련된 정보들을 제공하고 있어서, 오류 페이지에 이 정보를 활용하여 출력할 수도 있다. BasicErrorController에서 제공하고 있는 기본 정보들을 확인해보자!
BasicErrorController가 제공하는 기본 정보들
BasicErrorController 컨트롤러는 다음 정보를 model에 담아서 뷰에 전달한다. 뷰 템플릿은 이 값들을 활용해서 출력할 수 있다!
* timestamp: Fri Feb 05 00:00:00 KST 2021
* status: 400
* error: Bad Request
* exception: org.springframework.validation.BindException
* trace: 예외 trace
* message: Validation failed for object='data'. Error count: 1
* errors: Errors(BindingResult)
* path: 클라이언트 요청 경로 (`/hello`)오류 정보 추가: resource/templates/error/500.xml
<!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>
<div>
<p>오류 화면 입니다.</p>
</div>
<ul>
<li>오류 정보</li>
<ul>
<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>
<hr class="my-4">
</div> <!-- /container -->
</body>
</html>관련 정보를 사용자에게 제공하는 것이 가능하나, 사실 오류 관련 내부 정보들을 고개에게 노출하는 것이 바람직하다고 볼 순 없다. 고객이 해당 정보를 읽어봐야 혼란만 더해지고, 보안상 문제가 될 수도 있다. 그래서 BasicErrorController오류 컨트롤러에서 다음 오류 정보를 model에 포함할지 여부를 선택할 수 있다.
application.properties
server.error.include-exception=true
// exception 포함 여부 (true, false)
server.error.include-message=on_param
// message 포함 여부
server.error.include-stacktrace=on_param
// trace 포함 여부
server.error.include-binding-errors=on_param
// errors 포함 여부기본값이 never인 부분은 다음 3가지 옵션을 사용할 수 있다.
never, always, on_param
never: 사용하지 않음.always: 항상 사용on_param: 파라미터가 있을 때 사용. (파라미터가 있을때만 정보 노출)- on_param 설정 후 HTTP 요청시 파라미터를 전달하면 해당 정보들이 model에 담겨서 뷰 템플릿에 출력된다.
http://localhost:8080/error-ex?message=&errors=&trace=
실무에서는 이런 정보들을 노출해서는 안된다! 사용자에게는 예쁜 오류 화면과 고객이 이해할 수 있는 간단한 메시지를 보여주고, 오류는 서버에 로그로 남겨서 로그로 확인해야 한다.
스프링 부트 오류 관련 옵션
server.error.whitelabel.enabled=true: 오류 처리 화면을 못 찾으면 스프링에서 whiltelagel 오류 페이지를 적용해준다.server.error.path: 오류 페이지 경로, 스프링이 자동 등록하는 서블릿 글로벌 오류 페이지 경로와BasicErrorController오류 컨트롤러 경로에 함께 사용 된다.
확장 포인트!
에러 공통 처리 컨트롤러의 기능을 변경하고 싶으면,
1. ErrorController인터 페이스를 상속 받아 구현하거나,
2. BasicErrorController 상속받아서 기능을 추가하면 된다.
정리
-
결론: (스프링에서 다~ 만들어뒀다.)
resources>templates>error>아래에 http 에러 코드명으로 예쁜 오류 페이지를 제공하면, 스프링이 알아서 그 페이지 제공해준다! -
포인트:
- 서블릿의 예외 인식 방법: Exception, response.sendError (HTTP 상태 코드, 오류 메시지)
- 오류 발생 시, WAS가 오류 페이지를 재요청한다.
-> 준비물: (1.요청 url, 2.오류페이지 매핑할 컨트롤러, 3.view)
-> 불필요하게 & 의도치 않게 필터, 인터셉터가 재작동해야 한다.
-> DispatcherType을 통해 요청의 성질(오류 재요청? 첫요청?) 구분가능
+) 인터셉터는 이게 안되니까, 오류 페이지 재요청 경로(url)을 차단해야함. - 스프링이 다 구현해 뒀다. = (준비물 1.
/error2.BasicErrorController)
-> 준비물 3.template>error>아래 예쁜 템플릿만 넣어두면 된다.
