스프링 MVC 2편 - [8] 예외 처리와 오류 페이지

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2/dashboard

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 - 인프런 | 강의

인프런 김영한님의 스프링 MVC 2편 강의를 토대로 정리한 내용입니다.

 

[1] 서블릿 예외처리 - 시작

목표 : 스프링이 아닌 순수 서블릿 컨테이너에선 예외를 어떻게 처리하는지 알아보자.

서블릿부터 차근차근 원리를 찾아가는 게 이해하기 좋다.

 

서블릿의 예외 처리 2가지 방법

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

■ Exception(예외)

자바 직접 실행

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

 

웹 애플리케이션

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

1] 애플리케이션에서 예외가 발생했을 때 try catch로 예외를 잡아 처리하면 상관없다.

2] 그러나 애플리케이션에서 예외를 잡지 못하면 서블릿 밖으로 예외가 전달되고 만다.

 

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

 

스프링부트에서 제공하는 에러 페이지 꺼두기

application.properties

    server.error.whitelabel.enabled=false

 

실행화면 & ServletExController

1] 500 예외

톰캣이 기본으로 제공하는 오류화면(좌측)

Exception이 뜨면 서버 내부에서 처리할 수 없는 오류로 판단해 HTTP 상태 코드 500을 반환한다.

 

2] 404 예외 - Not Found

없는 페이지를 호출하면 톰캣이 제공하는 404 - Not Found가 뜬다.

 

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

오류가 발생했을 때 HttpServletResponse가 제공하는 sendError라는 메서드를 사용해도 된다.

 

ServletExController - 추가

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

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

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

sendError를 쓰면 HTTP 상태코드(ex 404, 400, 500)와 오류 메시지도 추가 가능하다.

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

 

 

sendError의 흐름

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

① respose.sendError()를 호출하면 이 메서드는 response 내부에 오류가 발생했다는 상태를 저장해 둔다.

② 서블릿 컨테이너는 고객에게 응답하기 전 response에 sendError()가 호출된 지 확인하고 호출됐으면 설정한 오류 코드에 맞춰 기본 오류 페이지를 보여준다.

 

 

[2] 서블릿 예외처리 - 오류 화면 제공

목표 : 서블릿 컨테이너가 제공하는 기본 예외 처리 화면은 고객 친화적이지 않다. 서블릿이 제공하는 오류 화면 기능을 통해 고객 친화적으로 바꿔보자.

 

WebServerCustomizer

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {

    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        //404 505
        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
        //Exception
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500");

        //에러페이지 등록
        factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
    }
}

500 예외가 서버 내부에서 발생한 오류라는 뜻을 포함하고 있기 때문에 예외가 발생한 케이스도 500 오류 화면으로 처리

 

이 오류를 처리할 컨트롤러와 html도 필요하다.

 

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

 

404 & 500.html

 

[3] 서블릿 예외처리 - 오류 페이지 작동 원리

서블릿은 Exception(예외)가 발생해 서블릿 밖으로 전달되거나 response.sendError()가 호출됐을 때 설정된 오류 페이지를 찾는다.

 

예외 발생 흐름

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

 

sendError 흐름

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

예외나 response.sendError()가 호출됐을 때 WAS는 해당 예외를 처리하는 오류 페이지 정보를 확인한다. 

RuntimeException이 터질 경우 오류 페이지로 /error-page/500이 지정돼 있으므로 /error-page/500을 다시 요청한다.

 

오류 페이지 요청 흐름

WAS `/error-page/500` 다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/error-page/500) -> View

 

예외 발생과 오류 페이지 요청 흐름

① 예외가 발생해 WAS까지 전달된다.

② WAS가 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다. 이때 오류 페이지 경로로 필터, 인터셉터, 컨트롤러가 모두 다시 호출되는 걸 확인할 수 있다.

=> 필터, 인터셉터가 재호출 되는 비효율을 없애는 법은 [4] [5]에서 확인할 예정이다.

 

중요한 건 클라이언트는 서버 내부에서 내부 호출이 일어나는 걸 전혀 모른다는 점이다. 

 

■ 오류 정보 추가

WAS는 오류 페이지를 요청하는 것 외에 오류 정보를 request의 attribute에 담아 넘겨주는 기능이 있다.

 

 

ErrorPageController - 오류 출력

@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");
        printErrorInfo(request);
        return "error-page/404";
    }

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

    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("dispatchType={}", request.getDispatcherType());
    }
}

 

실행 로그

① javax.servlet.error.exception : 예외 => ex) errorPage 404, errorPage 500
② javax.servlet.error.exception_type : 예외 타입 => ex) RuntimeException
③ javax.servlet.error.message : 오류 메시지 => ex) 예외 발생!
④ javax.servlet.error.request_uri : 클라이언트요청 URI => ex) /error-ex
⑤ javax.servlet.error.servlet_name : 오류가 발생한 서블릿 이름 => ex) dispatcherServlet
⑥ javax.servlet.error.status_code : HTTP 상태코드 => ex) 500

⑦ 디스패처 타입은 [4] 서블릿 예외처리 - 필터에서 설명할 예정

 

 

[4] 서블릿 예외처리 - 필터

목표 : 필터와 관련된 예외처리, 서블릿이 제공하는 DispatchType 이해하기

 

위에서 오류가 발생하면 오류페이지를 출력하기 위해 필터, 서블릿, 인터셉터가 재호출 되는 걸 확인할 수 있었다. 그런데 필터, 서블릿, 인터셉터가 필요하지 않은데 재호출 되는 건 매우 비효율적인 일이다.

그래서 클라이언트로부터 발생한 요청이 정상적인 요청인지 오류 페이지를 출력하기 위한 내부 요청인지 구분할 필요가 있고, 서블릿은 이런 문제를 해결하기 위해 DispatcherType이라는 추가 정보를 제공한다.

 

■ DispatcherType

위 실행로그 ⑦에서 log를 출력한 결과 dispatchType=ERROR가 나온 것을 확인할 수 있다. 그런데 고객이 처음 요청할 때 log는 dispatchType=REQUEST다. 이를 통해 REQUEST가 클라이언트 요청, ERROR가 오류 요청인 것을 확인할 수 있다.

 

참고로 DispatcherType은 REQUEST, ERROR 외에 다른 타입도 제공한다.

① REQUEST : 클라이언트요청 
② ERROR : 오류 요청
③ FORWARD : MVC에서 배웠던 서블릿에서 다른 서블릿이나 JSP를 호출할 때 
    => RequestDispatcher.forward(request, response);
④ INCLUDE : 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때 
    => RequestDispatcher.include(request, response);
⑤ ASYNC : 서블릿 비동기호출

 

■ 필터와 DispatcherType

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

기존 강의에서 쓰던 LogFilter의 로그 부분에 request.getDispatcherType()만 추가된 것을 확인할 수 있다.

 

WebConfig

@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Bean
    public FilterRegistrationBean logFilter() {
        FilterRegistrationBean<Filter> filterFilterRegistrationBean = new FilterRegistrationBean<>();

        filterFilterRegistrationBean.setFilter(new LogFilter());
        filterFilterRegistrationBean.setOrder(1);
        filterFilterRegistrationBean.addUrlPatterns("/*");
        filterFilterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);

        return filterFilterRegistrationBean;
    }

}

filterRegistrationBean.setDispatcherTypes()에 DispatcherType.REQUEST, DispatcherType.ERROR를 추가하면 두 타입에도 필터가 적용된다. default값은 DispatcherType.REQUEST 하나다.

 

실행로그

LogFilter가 REQUEST뿐만 아니라 RESPONSE에서도 사용된 것을 확인할 수 있다. 두 번 사용됐다는 의미다.

물론 default값으로 넣으면 RESPONSE 한 번만 LogFilter가 호출된다.

 

 

[5] 서블릿 예외처리 - 인터셉터

목표 : 인터셉터에선 중복 호출을 어떻게 제거해야 할까?

 

인터셉터는 스프링이 제공하는 기능이라 DispatcherType과 무관하게 항상 호출된다. 대신 인터셉터에는 요청 경로에 따라 인터셉터 적용을 하거나 제외하는 게 쉽게 되어 있기 때문에 오류 페이지 경로를 excludePathPatterns를 사용해 빼면 된다.

 

LogInterceptor - DispatcherType 로그 추가

@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 - 인터셉터

@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/**");//인터셉터는 필터처럼 디스패처 타입 없음. 대신 excludePatterns 사용
    }
    
    //@Bean
    public FilterRegistrationBean logFilter() {...}

① excludePathPatterns에 /error-page/**를 넣으면 내부 호출 시 인터셉터가 호출되지 않는다.

② LogFilter는 호출되지 않게 @Bean을 주석 처리

 

■ 전체 흐름 정리

1] 정상요청

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

 

2] 오류요청

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

 

[6] 스프링 부트 - 오류 페이지 1

앞서 예외 처리 페이지를 만들기 위해 ①WebServerCustomizer를 만들고 ②예외 종류에 맞춰 ErrorPage를 추가하고 ③ ErrorPageController를 만드는 복잡한 과정을 거쳤다. 

 

그런데 스프링부트는 이런 과정을 기본으로 제공한다.

① ErrorPage를 자동으로 등록한다. 이때 /error/오류코드.html을 오류페이지의 경로로 인식한다.

② 스프링 부트에서 BasicErrorController를 자동으로 등록한다.

    => ErrorPage에 등록한 /error를 매핑해서 처리하는 컨트롤러다.

③ 개발자는 오류 페이지만 등록하면 된다.

    => 정적 HTML은 정적 리소스, 동적 페이지를 만들고 싶으면 뷰 템플릿 경로에 오류 페이지 파일을 만들어 넣으면 된다.

 

■ 뷰 선택 우선순위

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

① 뷰 템플릿이 정적 리소스보다 우선순위가 높다. 아울러 404, 500처럼 구체적인 페이지가 4xx, 5xx처럼 덜 구체적인 페이지보다 우선순위가 높다. 

② 4xx는 400번대 5xx는 500번대 오류를 처리해 준다.

 

 

[7] 스프링 부트 - 오류 페이지 2

BasicController는 오류 관련 다양한 정보를 model에 담아 뷰에 전달한다. 뷰 템플릿은 이 값을 활용해 화면에 출력할 수 있다.

 

브라우저 화면 & resources/templates/error/500.html

단, 오류 관련 내부 정보를 고객에게 노출하는 것은 바람직하지 않다. 고객에게 혼란을 가중할 수 있으며 보안상(쓰는 라이브러리가 노출되면 해커들이 이 라이브러리의 취약점을 이용해 해킹할 수 있기 때문)으로도 좋지 않다. 

 

그래서 BasicController에서 다음 오류 정보를 model에 포함할지 여부를 선택할 수 있다.

 

application.properties

• 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인 부분은 다음 3가지 옵션을 사용할 수 있다.

• never : 사용하지 않음
• always :항상 사용
• on_param : 파라미터가 있을 때 사용

 

on_param 실행화면

 

on_param은 파라미터가 있으면 해당 정보를 노출한다. 없으면 바로 위 스크린샷처럼 해당 정보를 노출하진 않는다. on_param도 개발 서버에선 사용할 수 있지만, 운영 서버에서는 권장하지 않는다.

 

■ 스프링부트 오류 관련 옵션

① server.error.whitelabel.enabled=true : 오류 처리 화면을 못 찾을 시 스프링 whitelabel 오류 페이지 적용
② server.error.path=/error : 오류 페이지 경로, 스프링이 자동 등록하는 서블릿 글로벌 오류 페이지 경로와 BasicErrorController 오류 컨트롤러 경로에 함께 사용된다.

 

■ 확장 포인트

에러 공통처리 컨트롤러 기능을 변경하고 싶으면 ErrorController 인터페이스나 BasicController를 상속받은 후 기능을 추가하면 된다.