[Spring] 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 섹션8 예외 처리와 오류 페이지

본 내용은 인프런 김영한T 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 강의를 정리한 내용입니다:)

[Spring] 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 섹션8 예외 처리와 오류 페이지

◼️ 서블릿 예외 처리

🟢 서블릿 예외처리 두가지 방식

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

애플리케이션에서 예외를 잡지 못하고 서블릿 밖까지 예외가 전달되면 아래와 같이 WAS와 까지 예외가 전달된다.

• WAS(여기까지 전파) ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러(예외발생)
• WAS(sendError 호출 기록 확인) ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러(response.sendError())

▪️예외(Exception)를 호출해보자.

server.error.whitelabel.enabled=false //application.properties

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

HTTP Status 500 – Internal Server Error

 

▪️response.sendError(HTTP 상태 코드, 오류 메시지)를 호출해보자.

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

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

◼️ 서블릿 예외 처리 - 오류 화면 제공

서블릿은 오류 화면 기능을 제공한다. 오류페이지는 자식 타입 오류를 함께 처리한다.

예를 들어서 RuntimeException 은 물론이고 RuntimeException 의 자식도 함께 처리한다.

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

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

◼️ 서블릿 예외 처리 - 오류 페이지 작동 원리

예외가 발생해서 WAS까지 전파되고, WAS는 예외를 처리하는 오류페이지 정보를 확인한다.

ErrorPage errorPageEx = new ErrorPage(RuntimeException.class,"error-page/500");

이때 오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다.

WAS는 오류 페이지를 요청하면서 오류 정보 또한 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 상태 코드

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: ex=", request.getAttribute(ERROR_EXCEPTION));
        log.info("ERROR_EXCEPTION_TYPE: {}", request.getAttribute(ERROR_EXCEPTION_TYPE));
        log.info("ERROR_MESSAGE: {}", request.getAttribute(ERROR_MESSAGE)); //ex의 경우 NestedServletException 스프링이 한번 감싸서 반환
        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());
    }
}

◼️ 서블릿 예외 처리 - 필터

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

• WAS(여기까지 전파) ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러(예외발생)
•  WAS (/error-page/500) 다시 요청 → 필터 → 서블릿 → 인터셉터 → 컨트롤러(/error-page/500) → View

오류가 발생하면 필터or인터셉트가 한번 더 호출되기 때문에, 오류 페이지 출력을 위한 내부 요청을 구별할 수 있어야한다,

 

🟢 DispatcherType

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

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

}

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Bean
    public FilterRegistrationBean logFilter() {
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new LogFilter());
        filterRegistrationBean.setOrder(1);
        filterRegistrationBean.addUrlPatterns("/*");
        // 클라이언트 요청(default), 오류페이지 요청에서 필터 호출
        filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST,DispatcherType.ERROR);
        return filterRegistrationBean;
    }
}

위에서 setDispatcherTypes()는 REQUEST가 기본 값이다. 클라이언트 요청이 있는 경우에만 필터가 적용된다.

오류 페이지 요청 전용 필터를 적용하고 싶으면  DispatcherType.ERROR 만 지정하면 된다.

클라이언트의 요청이 있는 경우에만 필터가 적용된다. 특별히 오류 페이지 경로도 필터를 적용할 것이 아니면, 기본 값을 그대로 사용하면 된다.

실행결과. Dispatcher가 type을 구분해 주는 것을 확인할 수 있다.:)

◼️ 서블릿 예외 처리 - 인터셉터

인터셉터는 서블릿 제공이 아니라 스프링 제공 기능이기 때문에 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);
        }
    }
}

@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/**" //오류 페이지 경로
                );
    }...//인터셉터와 중복으로 처리되지 않기 위해 앞의 logFilter() 의 @Bean 에 주석

🟢 전체 흐름 정리

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 만들기
2. 예외 종류에 따라 Errorpage 추가
3. 예외 처리용 컨트롤러 ErrorPageController 만들기

◼️ 스프링 부트 - 오류 페이지1

시작전 스프링 부트가 제공하는 기본 오류 메커니즘을 사용하도록 WebServerCustomizer에 있는 @Component 를 주석 처리한다.

 

🟢 스프링 부트의 예외처리

• /error라는 경로로 기본 오류 페이지 설정
• BasicErrorController라는 스프링 컨트롤러 자동 등록 (/error 매핑 처리)

따라서 개발자는 BasicErrorController제공 룰에 따라 오류 페이지만 등록하면 된다.

🪄 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

* 뷰 템플릿이 정적 리소스보다 우선 순위가 높고, 구체적인 것이(500) 덜 구체적인 것(5xx)보다 우선순위가 높다.

 

아래 오류 페이지를 등록하고 테스트를 해보자.

• resources/templates/error/4xx.html
• resources/templates/error/404.html
• resources/templates/error/500.html

테스트 결과
http://localhost:8080/error-404 → 404.html
http://localhost:8080/error-400 → 4xx.html (400 오류 페이지가 없지만 4xx가 있음)
http://localhost:8080/error-500 → 500.html
http://localhost:8080/error-ex → 500.html (예외는 500으로 처리)

◼️ 스프링 부트 - 오류 페이지2

🟢 BasicErrorController 제공 기본 정보들

아래처럼 model에 정보를 담아 뷰에서 이를 출력할 수 있다.

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

오류 관련 내부 정보를 고객에게 노출하는 것은 좋지않다.실무에서는 오류는 서버에 로그로 남기고 외부에 노출하면 안된다.

BasicErrorController 오류 컨트롤러에서 오류 정보를 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인부분의 옵션 설정: never 사용하지 않음, always 항상 사용, on_param 파라미터가 있을때 사용

server.error.include-exception=true
server.error.include-message=on_param
server.error.include-stacktrace=on_param
server.error.include-binding-errors=on_param

 

에러 공통 처리 컨트롤러 기능 변경은 ErrorController를 상속받아서 구현하거나 BasicErrorController를 상속받아 기능을 추가하면된다.