[김영한 스프링 MVC 2] 예외 처리와 오류 페이지

서블릿 예외 처리 

 

시작

 

순수 서블릿 컨테이너가 예외 처리하는 방법 

 

1. Exception (예외)

 

1) 자바 직접 실행

자바의 메인 메서드를 직접 실행하면 main이라는 이름의 스레드가 실행된다.
실행 중 main 메서드를 넘어 예외가 던져지면, 예외 정보를 남기고 해당 스레드가 종료된다.

 

2) 웹 애플리케이션

웹 애플리케이션은 사용자 요청별로 별도의 스레드가 할당되고, 서블릿 컨테이너 안에서 실행된다.

애플리케이션에서 예외를 잡지 못해 서블릿 밖으로까지 예외가 전달되면 하단의 과정을 거친다.

WAS <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외 발생)

 

 

• WAS로 예외 전달됐을 때 처리 예시

@Controller
public class ServletExController {

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

//...

 

=>

톰캣이 기본으로 제공하는 오류 화면을 볼 수 있다

 

 

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

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

오류 발생 시 HttpServletResponse의 sendError 메서드를 사용해도 된다.

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

 

 

• ServletExController

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

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

 

 

• 호출 흐름

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

 

sendError 호출

-> response 내부에 오류 발생한 상태를 저장

-> 서블릿 컨테이너는 해당 상태 확인 시 설정된 오류 코드에 맞춰 기본 오류 페이지 보여줌

 

 

 

오류 화면 제공

 

과거에는 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>

 

 

지금은 스프링부트가 제공하는 기능을 사용해 서블릿 오류 페이지 등록하면 됨

 

 

• WebServerCustomizer

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {

    // 웹서버 커스터마이징 - 오류 페이지 커스터마이징
    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404"); // 404면 해당 컨트롤러 호출
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500"); // RuntimeException or 자식 타입 예외 -> errorPageEx 호출

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

}

 

 

•  ErrorPageController

@Controller
@Slf4j
public class ErrorPageController { // 오류 페이지 화면 위한 컨트롤러

    @RequestMapping("/error-page/404")
    public String errorPage404(HttpServletRequest req, HttpServletResponse res){
        log.info("errorPage 404");

        return "error-page/404"; //// /templates/error-page/404 에 있는 오류 페이지 화면 보여줌
    }

    @RequestMapping("/error-page/500")
    public String errorPage500(HttpServletRequest req, HttpServletResponse res){
        log.info("errorPage 500");

        return "error-page/500";
    }

}

 

 

 

오류 페이지 작동 원리

 

• 예외 발생 -> 오류 페이지 요청 흐름

1. WAS <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외 발생)
2. WAS '/error-page/500' 재요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/error-page/
500) -> View

 

 

1. 예외가 발생해서 WAS까지 전파된다.
2. WAS는 오류 페이지 경로를 찾아 내부에서 오류 페이지를 호출한다. 이때 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다.

 

웹 브라우저(클라이언트)는 서버 내부의 일에 대해서는 전혀 모른다. 오직 서버 내부에서 오류 페이지를 찾기 위해 추가로 호출한다.

 

 

• 오류 정보 추가 (request.getAttribute)

@Controller
@Slf4j
public class ErrorPageController { // 오류 페이지 화면 위한 컨트롤러

    @RequestMapping("/error-page/404")
    public String errorPage404(HttpServletRequest req, HttpServletResponse res){
        log.info("errorPage 404");

        printErrorInfo(req);

        return "error-page/404";
    }

    @RequestMapping("/error-page/500")
    public String errorPage500(HttpServletRequest req, HttpServletResponse res){
        log.info("errorPage 500");

        printErrorInfo(req);

        return "error-page/500";
    }

    private void printErrorInfo(HttpServletRequest req){
         log.info("ERROR_EXCEPTION_TYPE: {}", req.getAttribute(RequestDispatcher.ERROR_EXCEPTION_TYPE)); ////
         log.info("ERROR_EXCEPTION: {}", req.getAttribute(RequestDispatcher.ERROR_EXCEPTION)); ////
         log.info("ERROR_MESSAGE: {}", req.getAttribute(RequestDispatcher.ERROR_MESSAGE)); ////
         log.info("ERROR_REQUEST_URI: {}", req.getAttribute(RequestDispatcher.ERROR_REQUEST_URI)); ////
         log.info("ERROR_SERVLET_NAME: {}", req.getAttribute(RequestDispatcher.ERROR_SERVLET_NAME)); ////
         log.info("ERROR_STATUS_CODE: {}", req.getAttribute(RequestDispatcher.ERROR_STATUS_CODE)); ////

         log.info("dispatchType={}", req.getDispatcherType()); ////
    }

}

 

 

 

필터

 

오류 발생 시 오류 페이지를 출력하기 위해 WAS 내부에서 다시 호출이 발생 (필터, 서블릿, 인터셉터 재호출)
=> 오류 페이지 표시를 위해 로그인 체크 등을 위한 필터/인터셉터가 또 호출되는 것은 비효율적

=> 이를 해결하기 위해 서블릿은 정상 요청/오류 페이지 요청인지 구분하는 DispatcherType을 제공한다.

 

※ DispatcherType

public enum DispatcherType {
 FORWARD,
 INCLUDE,
 REQUEST,
 ASYNC,
 ERROR
}

 

REQUEST : 클라이언트 요청
ERROR : 오류 요청
FORWARD : 서블릿에서 다른 서블릿/JSP를 호출할  때 ex. RequestDispatcher.forward(request, response);
INCLUDE : 서블릿에서 다른 서블릿/JSP의 결과를 포함할 때 ex. RequestDispatcher.include(request, response);
ASYNC : 서블릿 비동기 호출

 

 

• LogFilter

@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) {
            log.info("EXCEPTION [{}]", e.getMessage());
            throw e;
        } finally {
            log.info("RESPONSE [{}][{}][{}]", uuid, request.getDispatcherType(), requestURI); ////
        }
    }

    @Override
    public void destroy() {
        log.info("log filter destroy");
    }

}

 

 

• WebConfig

    @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.setDispatcherTpyes 기본값 : REQUEST 

=> 클라이언트 정상 요청일 때만 호출됨

 

 

 

인터셉터

 

• LogInterceptor

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

}

 

 

• WebConfig

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns("/css/**", "*.ico", "/error", "/error-page/**"); 
                //// 오류 페이지 경로 제외
    }

 

스프링이 제공하는 기능인 인터셉터는 DispatcherType이 아닌 요청 경로에 따라 호출에 포함/제외한다.

 

 

 

흐름 정리

 

 

• 정상 요청 (/hello)

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

 

 

• 오류 요청 (/error-ex )

1. WAS(/error-ex, dispatchType=REQUEST) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러
2. WAS <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외 발생)
3. WAS 오류 페이지 확인
4. WAS(/error-page/500, dispatchType=ERROR) -> 필터(x) -> 서블릿 -> 인터셉터(x) -> 컨트롤러(/error-page/500) -> View

 

필터 => DispatchType 으로 중복 호출 제거 ( dispatchType=REQUEST )
인터셉터 => 경로 정보로 중복 호출 제거( excludePathPatterns("/error-page/**") )

 

 

 

 

스프링부트

 

 

오류 페이지 1

 

WebServerCustomizer 생성, 예외 종류에 따라서 ErrorPage 추가, 예외 처리용 컨트롤러 ErrorPageController 생성 등의 과정
=> 스프링 부트가 기본 제공

 

1. ErrorPage 자동 등록

/error 라는 경로로 기본 오류 페이지를 설정한다.

=> 서블릿 밖으로 예외 발생, response.sendError(...) 호출 시 모든 오류는 /error를 호출

2. BasicErrorController 자동 등록

ErrorPage에서 등록한 /error를 매핑해서 처리

=> 기본적인 로직이 모두 개발되어 있어, 개발자는 오류페이지만 특정 경로에 등록하면 된다. 

 

※ ErrorMvcAutoConfiguration이 오류 페이지를 자동으로 등록해줌

 

 

• 뷰 선택 우선순위 (BasicErrorController 처리 순서)

1. 뷰 템플릿
resources/templates/error/500.html
resources/templates/error/5xx.html

2. 정적 리소스( static , public )
resources/static/error/400.html
resources/static/error/404.html
resources/static/error/4xx.html

3. 적용 대상이 없을 때 뷰 이름( error )
resources/templates/error.html

 

해당 경로에 HTTP 상태 코드 이름의 뷰 파일을 생성하면 스프링부트가 처리한다.
뷰 템플릿이 정적 리소스보다 우선순위가 높고, 404처럼 구체적인 것이 4xx보다 우선순위가 높다.

 

 

 

오류 페이지 2

 

• BasicErrorController가 제공하는 기본 정보들

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`)

 

<!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>

 

이러한 내부 정보는 고객에 노출하면 혼란만 가중시키고 보안상 문제가 될 수 있다. 

 

application.properties

# default
server.error.include-exception=false # exception 포함 여부( true , false )
server.error.include-message=never # message 포함 여부
server.error.include-stacktrace=never # trace 포함 여부
server.error.include-binding-errors=never # errors 포함 여부

 

never : 사용하지 않음

always :항상 사용

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

 

 

※

에러 공통 처리 컨트롤러의 기능을 변경하고 싶으면 ErrorController 인터페이스를 상속 받거나 BasicErrorController를 상속 받으면 된다