스프링 MVC 2편 - 백엔드 웹 개발 활용 기술
  1. Spring mvc2 타임리프 기본기능
  2. Spring mvc2 타임리프 스프링 통합과 폼
  3. Spring mvc2(2) 메세지, 국제화
  4. Spring mvc2(3) 검증1 validation
  5. Spring mvc2 검증2 1 bean validation
  6. Spring mvc2 검증2 2 로그인 처리1 쿠키, 세션
  7. Spring mvc2 검증2 3 로그인 처리2 필터, 인터셉터
  8. Spring mvc2 검증2 4 예외 처리와 오류 페이지
  9. Spring mvc2(1) api 예외처리
  10. Spring mvc2(2) 스프링 타입 컨버터
  11. Spring mvc2(3) 파일 업로드
목록보기

1. 서블릿 예외 처리 - 시작

서블릿은 다음 2가지 방식으로 예외 처리를 지원한다.

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

Exception(예외)

자바 직접 실행

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

웹 애플리케이션

  • 웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다.
  • 애플리케이션에서 예외가 발생했는데, 어디선가 try ~ catch로 예외를 잡아서 처리하면 아무런 문제가 없다.
  • 그런데 만약에 애플리케이션에서 예외를 잡지 못하고, 서블릿 밖으로 까지 예외가 전달되면 어떻게 동작할까?

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

  • 결국 톰캣 같은 WAS 까지 예외가 전달된다. WAS는 예외가 올라오면 어떻게 처리해야 할까?

ServletExController - 서블릿 예외 컨트롤러

  • 먼저 스프링 부트가 제공하는 기본 예외 페이지가 있는데 이건 꺼둔다.

  • server.error.whitelabel.enabled=false (application.properties)

  • package hello.exception.servlet;
  
import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
  
import java.io.IOException;
  
@Slf4j
@Controller
public class ServletExController {
    @GetMapping("/error-ex")
    public void errorEx() {
        throw new RuntimeException("에외 발생!");
    }
  
    @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, "500 오류!");
    }
}

  • 실행해보면 다음처럼 tomcat이 기본으로 제공하는 오류 화면을 볼 수 있다.

    • HTTP Status 500 – Internal Server Error

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

  • 오류가 발생했을 때 HttpServletResponse 가 제공하는 sendError 라는 메서드를 사용해도 된다.
  • 이것을 호출한다고 당장 예외가 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다.
  • 이 메서드를 사용하면 HTTP 상태 코드와 오류 메시지도 추가할 수 있다.
    • response.sendError(HTTP 상태 코드)
    • response.sendError(HTTP 상태 코드, 오류 메시지)

sendError 흐름

  • WAS(sendError 호출 기록 확인) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러
  • response.sendError() 를 호출하면 response 내부에는 오류가 발생했다는 상태를 저장해둔다.
  • 그리고 서블릿 컨테이너는 고객에게 응답 전에 response 에 sendError() 가 호출되었는지 확인한다.
  • 그리고 호출되었다면 설정한 오류 코드에 맞추어 기본 오류 페이지를 보여준다.

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

  • .서블릿이 제공하는 오류 화면 기능을 사용해보자
  • 서블릿은 Exception (예외)가 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError() 가 호출 되었을 때 각각의 상황에 맞춘 오류 처리 기능을 제공한다.

서블릿 오류 페이지 등록

  • 지금은 스프링 부트를 통해서 서블릿 컨테이너를 실행하기 때문에, 스프링 부트가 제공하는 기능을 사용해서 서블릿 오류 페이지를 등록하면 된다.

  • 주석 참고

  • package hello.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) {
  
        //WAS 까지 오류값이 넘어왔을 때 여기서 오류페이지를 찾아서 넘기게 된다.
        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);
    }
}

오류처리 컨트롤러(ErrorPageController)

  • package hello.exception.servlet;
  
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
  
@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";
    }
}
    • 404 에러가 뜨면 -> WAS 까지 넘어가서 ErrorPage errorPage404 호출 -> ErrorPageController 에서 “/error-page/404” 호출 -> 반환값으로 “/error-page/404” 렌더링

오류 페이지 뷰

404

  • /templates/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>

500

  • /templates/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>

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

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

예외 발생 흐름

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

sendError 흐름

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

WAS는 해당 예외를 처리하는 오류 페이지 정보를 확인한다.

new ErrorPage(RuntimeException.class, “/error-page/500”)

  • 예를 들어서 RuntimeException 예외가 WAS까지 전달되면, WAS는 오류 페이지 정보를 확인한다.
  • 확인해보니 RuntimeException 의 오류 페이지로 /error-page/500 이 지정되어 있다.
  • WAS는 오류 페이지를 출력하기 위해 /error-page/500 를 다시 요청한다.

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

  1. WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)
  2. WAS /error-page/500 다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/errorpage/500) -> View

중요한 점은 웹 브라우저(클라이언트)는 서버 내부에서 이런 일이 일어나는지 전혀 모른다는 점이다. 오직 서버 내부에서 오류 페이지를 찾기 위해 추가적인 호출을 한다

오류 정보 추가

  • WAS는 오류 페이지를 단순히 다시 요청만 하는 것이 아니라, 오류 정보를 request 의 attribute 에 추가해서 넘겨준다.
  • 필요하면 오류 페이지에서 이렇게 전달된 오류 정보를 사용할 수 있다.

ErrorPageController - 오류 출력

  • package hello.exception.servlet;
  
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
  
@Slf4j
@Controller
public class ErrorPageController {
  
    //RequestDispatcher 상수로 정의되어 있음
    public static final String ERROR_EXCEPTION = "jakarta.servlet.error.exception";
    public static final String ERROR_EXCEPTION_TYPE = "jakarta.servlet.error.exception_type";
    public static final String ERROR_MESSAGE = "jakarta.servlet.error.message";
    public static final String ERROR_REQUEST_URI = "jakarta.servlet.error.request_uri";
    public static final String ERROR_SERVLET_NAME = "jakarta.servlet.error.servlet_name";
    public static final String ERROR_STATUS_CODE = "jakarta.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());
    }
}

request.attribute에 서버가 담아준 정보

  • jakarta.servlet.error.exception : 예외
  • jakarta.servlet.error.exception_type : 예외 타입
  • jakarta.servlet.error.message : 오류 메시지
  • jakarta.servlet.error.request_uri : 클라이언트 요청 URI
  • jakarta.servlet.error.servlet_name : 오류가 발생한 서블릿 이름
  • jakarta.servlet.error.status_code : HTTP 상태 코드

Tip : alt + shift + insert = Column Selection Mode (여러줄을 한 번에 입력가능)

4. 서블릿 예외 처리 - 필터

예외 발생 시 filter 가 두번 호출되는 문제

  • 오류가 발생하면 오류 페이지를 출력하기 위해 WAS 내부에서 다시 한번 호출이 발생한다.
  • 이때 필터, 서블릿, 인터셉터도 모두 다시 호출된다.
  • **그런데 로그인 인증 체크 같은 경우를 생각해보면, 이미 한번 필터나, 인터셉터에서 로그인 체크를 완료했다. 따라서 서버 내부에서 오류 페이지를 호출한다고 해서 해당 필터나 인터셉트가 한번 더 호출되는 것은 매우 비효율적이다. **
  • 결국 클라이언트로 부터 발생한 정상 요청인지, 아니면 오류 페이지를 출력하기 위한 내부 요청인지 구분할 수 있어야 한다.
  • 서블릿은 이런 문제를 해결하기 위해 DispatcherType 이라는 추가 정보를 제공한다.

DispatcherType

  • 필터는 이런 경우를 위해서 dispatcherTypes 라는 옵션을 제공한다.
  • 서블릿 스펙은 실제 고객이 요청한 것인지, 서버가 내부에서 오류 페이지를 요청하는 것인지 DispatcherType 으로 구분할 수 있는 방법을 제공한다.

javax.servlet.DispatcherType

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

필터와 DispatcherType

LogFilter - DispatcherType 로그 추가

  • 저번에 만들었던 LogFilter 와 비슷하다.

  • package hello.exception.filter;
import lombok.extern.slf4j.Slf4j;
import jakarta.servlet.*;
import jakarta.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 hello.exception;
  
import hello.exception.filter.LogFilter;
import jakarta.servlet.DispatcherType;
import jakarta.servlet.Filter;
import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
  
@Configuration
public class WebConfig implements WebMvcConfigurer {
  
    @Bean
    public FilterRegistrationBean logFilter(){
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new LogFilter());
        filterRegistrationBean.setOrder(1);
        filterRegistrationBean.addUrlPatterns("/*");
        //이 필터는 dispatchType 이 request 와 error 일때 호출된다.
        filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);
  
        return filterRegistrationBean;
    }
}

filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);

  • 이렇게 두 가지를 모두 넣으면 클라이언트 요청은 물론이고, 오류 페이지 요청에서도 필터가 호출된다.
  • 아무것도 넣지 않으면 기본 값이 DispatcherType.REQUEST 이다. 즉 클라이언트의 요청이 있는 경우에만 필터가 적용된다.
  • 특별히 오류 페이지 경로도 필터를 적용할 것이 아니면, 기본 값을 그대로 사용하면 된다.
  • 물론 오류 페이지 요청 전용 필터를 적용하고 싶으면 DispatcherType.ERROR 만 지정하면 된다.

로그

/error-ex 호출 시

  1. LogFilter : REQUEST [118adea4-c18e-457b-a916-772939a03b15][REQUEST][/error-ex]
  2. LogFilter : RESPONSE [118adea4-c18e-457b-a916-772939a03b15][REQUEST][/error-ex]
  3. RuntimeException: 예외 발생!
  4. LogFilter : REQUEST [0a1bfd9f-b70f-4a5b-ba9b-2ad313b5bd84][ERROR][/error-page/500]
  5. ErrorPageController : errorPage 500
  6. LogFilter : RESPONSE [0a1bfd9f-b70f-4a5b-ba9b-2ad313b5bd84][ERROR][/error-page/500]

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

LogInterceptor - DispatcherType 로그 추가

  • package hello.exception.interceptor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.servlet.HandlerInterceptor;
import org.springframework.web.servlet.ModelAndView;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.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 과 무관하게 항상 호출된다.

WebConfig 등록

  • 대신에 인터셉터는 다음과 같이 요청 경로에 따라서 추가하거나 제외하기 쉽게 되어 있기 때문에, 이러한 설정을 사용해서 오류 페이지 경로를 excludePathPatterns 를 사용해서 빼주면 된다.

  • @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns("/css/**", "*.ico", "/error", "/error-page/**");
    }
    • 여기에서 /error-page/** 를 제거하면 error-page/500 같은 내부 호출의 경우에도 인터셉터가 호출된다.

전체 흐름 정리

/error-ex 오류 요청 시

  • 필터는 DispatchType 으로 중복 호출 제거 ( dispatchType=REQUEST )
  • 인터셉터는 경로 정보로 중복 호출 제거( excludePathPatterns(“/error-page/**”) )
  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

지금까지의 과정 (filter, interceptor)

  • WebServerCustomizer 를 만들고
  • 예외 종류에 따라서 ErrorPage 를 추가하고
  • 예외 처리용 컨트롤러 ErrorPageController 를 만

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

스프링 부트가 제공하는 error 페이지 과정

  • ErrorPage 를 자동으로 등록한다. 이때 /error 라는 경로로 기본 오류 페이지를 설정한다.
    • new ErrorPage(“/error”) , 상태코드와 예외를 설정하지 않으면 기본 오류 페이지로 사용한다.
    • 서블릿 밖으로 예외가 발생하거나, response.sendError(…) 가 호출되면 모든 오류는 /error 를 호출하게 된다.
  • BasicErrorController 라는 스프링 컨트롤러를 자동으로 등록한다.
    • ErrorPage 에서 등록한 /error 를 매핑해서 처리하는 컨트롤러다.

ErrorMvcAutoConfiguration 이라는 클래스가 오류 페이지를 자동으로 등록하는 역할을 한다.

이제 오류가 발생했을 때 오류 페이지로 /error 를 기본 요청한다. 스프링 부트가 자동 등록한 BasicErrorController 는 이 경로를 기본으로 받는다.

개발자는 오류 페이지만 등록

  • BasicErrorController 는 기본적인 로직이 모두 개발되어 있다.
  • 개발자는 오류 페이지 화면만 BasicErrorController 가 제공하는 룰과 우선순위에 따라서 등록하면 된다.
  • 정적 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처럼 구체적인 것이 5xx처럼 덜 구체적인 것 보다 우선순위가 높다.
  • 5xx, 4xx 라고 하면 500대, 400대 오류를 처리해준다.

오류 뷰 템플릿 추가

/4xx.html

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

/404.html

  • resources/templates/error/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>

/500.html

  • resources/templates/error/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>

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

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

오류 정보 추가 후 html 출력

  • resources/templates/error/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>
  <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>
    • image-20230316102158973
  • 오류 관련 내부 정보들을 고객에게 노출하는 것은 좋지 않다.
  • 고객이 해당 정보를 읽어도 혼란만 더해지고, 보안상 문제가 될 수도 있다. 그래서 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 인 부분은 다음 3가지 옵션을 사용할 수 있다 : never, always, on_param
    • never : 사용하지 않음
    • always :항상 사용
    • on_param : 파라미터가 있을 때 사용 (message=&errors=&trace=) -> param 값이 없어도 출력된다.

스프링 부트 오류 관련 옵션

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

확장 포인트

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

8. API 예외 처리 - @ExceptionHandler

그런데 API는 각 시스템 마다 응답의 모양도 다르고, 스펙도 모두 다르다. 예외 상황에 단순히 오류 화면을 보여주는 것이 아니라, 예외에 따라서 각각 다른 데이터를 출력해야 할 수도 있다. 그리고 같은 예외라고 해도 어떤 컨트롤러에서 발생했는가에 따라서 다른 예외 응답을 내려주어야 할 수 있다. 한마디로 매우 세밀한 제어가 필요하다. 앞서 이야기했지만, 예를 들어서 상품 API와 주문 API는 오류가 발생했을 때 응답의 모양이 완전히 다를 수 있다.

API 예외처리의 어려운 점

  • HandlerExceptionResolver 를 떠올려 보면 ModelAndView 를 반환해야 했다. 이것은 API 응답에는 필요하지 않다.
  • API 응답을 위해서 HttpServletResponse 에 직접 응답 데이터를 넣어주었다. 이것은 매우 불편하다. 스프링 컨트롤러에 비유하면 마치 과거 서블릿을 사용하던 시절로 돌아간 것 같다.
  • 특정 컨트롤러에서만 발생하는 예외를 별도로 처리하기 어렵다. 예를 들어서 회원을 처리하는 컨트롤러에서 발생하는 RuntimeException 예외와 상품을 관리하는 컨트롤러에서 발생하는 동일한 RuntimeException 예외를 서로 다른 방식으로 처리하고 싶다면 어떻게 해야할까?

@ExceptionHandler

  • 스프링은 API 예외 처리 문제를 해결하기 위해 @ExceptionHandler 라는 애노테이션을 사용하는 매우 편리한 예외 처리 기능을 제공한다.
  • 이것이 바로 ExceptionHandlerExceptionResolver 이다
  • 스프링은 ExceptionHandlerExceptionResolver 를 기본으로 제공하고, 기본으로 제공하는 ExceptionResolver 중에 우선순위도 가장 높다.

예제

ErrorResult

  • 예외가 발생했을 때 API 응답으로 사용하는 객체를 정의했다.

  • package hello.exception.exhandler;
  
import lombok.AllArgsConstructor;
import lombok.Data;
  
@Data
@AllArgsConstructor
public class ErrorResult {
    private String code;
    private String message;
}

ApiExceptionV2Controller

  • package hello.exception.api;
  
import ...;
  
@Slf4j
@RestController
public class ApiExceptionV2Controller {
  
    //ResponseStatus 이 없으면 200 이 간다.
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(IllegalArgumentException.class)
    public ErrorResult illegalExHandler(IllegalArgumentException e){
        log.error("[exceptionHandler] ex", e);
        return new ErrorResult("BAD", e.getMessage());
    }
  
    @ExceptionHandler
    public ResponseEntity<ErrorResult> userExHandler(UserException e){
        log.error("[exceptionHander] ex]", e);
        ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
        return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
    }
  
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler
    public ErrorResult exHandler(Exception e) {
        log.error("[exHandler] ex]", e);
        return new ErrorResult("EX", "내부 오류");
    }
  
    @GetMapping("/api2/members/{id}")
    public ApiExceptionController.MemberDto getMember(@PathVariable("id") String id) {
  
        if (id.equals("ex")) {
            throw new RuntimeException("잘못된 사용자");
        }
        if (id.equals("bad")) {
            throw new IllegalArgumentException("잘못 입력된 값");
        }
        if (id.equals("user-ex")) {
            throw new UserException("사용자 오류");
        }
        return new ApiExceptionController.MemberDto(id, "hello " + id);
    }
  
    @Data
    @AllArgsConstructor
    static class MemberDto {
        private String memberId;
        private String name;
    }
}

@ExceptionHandler 예외 처리 방법

  • @ExceptionHandler 애노테이션을 선언하고, 해당 컨트롤러에서 처리하고 싶은 예외를 지정해주면 된다. 해당 컨트롤러에서 예외가 발생하면 이 메서드가 호출된다.

  • 참고로 지정한 예외 또는 그 예외의 자식 클래스는 모두 잡을 수 있다.

    우선순위 : 항상 자세한 것이 우선권을 가진다.

IllegalArgumentException 처리

  • @ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(IllegalArgumentException.class)
public ErrorResult illegalExHandler(IllegalArgumentException e){
    log.error("[exceptionHandler] ex", e);
    return new ErrorResult("BAD", e.getMessage());
}
    • @ResponseStatus(HttpStatus.BAD_REQUEST) : 400 에러 반환
    • @ExceptionHandler(IllegalArgumentException.class) : 이 컨트롤러에서 IllegalArgumentException 일 때 처리한다는 뜻

실행 흐름

  1. 컨트롤러를 호출한 결과 IllegalArgumentException 예외가 컨트롤러 밖으로 던져진다.
  2. 예외가 발생했으로 ExceptionResolver 가 작동한다. 가장 우선순위가 높은 ExceptionHandlerExceptionResolver 가 실행된다.
  3. ExceptionHandlerExceptionResolver 는 해당 컨트롤러에 IllegalArgumentException 을 처리할 수 있는 @ExceptionHandler 가 있는지 확인한다.
  4. illegalExHandle() 를 실행한다. @RestController 이므로 illegalExHandle() 에도 @ResponseBody 가 적용된다. 따라서 HTTP 컨버터가 사용되고, 응답이 다음과 같은 JSON으로 반환된다.
  5. @ResponseStatus(HttpStatus.BAD_REQUEST) 를 지정했으므로 HTTP 상태 코드 400으로 응답한다.

UserException 처리

  • @ExceptionHandler
public ResponseEntity<ErrorResult> userExHandle(UserException e) {
    log.error("[exceptionHandle] ex", e);
    ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
    return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
}
    • ResponseEntity 를 사용해서 HTTP 메시지 바디에 직접 응답한다. 물론 HTTP 컨버터가 사용된다.
    • **ResponseEntity 를 사용하면 HTTP 응답 코드를 프로그래밍해서 동적으로 변경할 수 있다. **
    • 앞서 살펴본 @ResponseStatus 는 애노테이션이므로 HTTP 응답 코드를 동적으로 변경할 수 없다.

Exception

  • @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
@ExceptionHandler
public ErrorResult exHandle(Exception e) {
    log.error("[exceptionHandle] ex", e);
    return new ErrorResult("EX", "내부 오류");
}
  • 그 외 모든 예외는 이 메서드가 처리한다.

HTML 오류 화면

  • 다음과 같이 ModelAndView 를 사용해서 오류 화면(HTML)을 응답하는데 사용할 수도 있다.

  • @ExceptionHandler(ViewException.class)
public ModelAndView ex(ViewException e) {
    log.info("exception e", e);
    return new ModelAndView("error");
}

9. API 예외 처리 - @ControllerAdvice

  • @ExceptionHandler 를 사용해서 예외를 깔끔하게 처리할 수 있게 되었지만, 정상 코드와 예외 처리 코드가 하나의 컨트롤러에 섞여 있다.
  • @ControllerAdvice 또는 @RestControllerAdvice 를 사용하면 둘을 분리할 수 있다.

ExControllerAdvice

  • package hello.exception.exhandler.advice;
  
import hello.exception.exception.UserException;
import hello.exception.exhandler.ErrorResult;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.RestControllerAdvice;
  
@Slf4j
@RestControllerAdvice
public class ExControllerAdvice {
  
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(IllegalArgumentException.class)
    public ErrorResult illegalExHandler(IllegalArgumentException e){
        log.error("[exceptionHandler] ex", e);
        return new ErrorResult("BAD", e.getMessage());
    }
  
    @ExceptionHandler
    public ResponseEntity<ErrorResult> userExHandler(UserException e){
        log.error("[exceptionHander] ex]", e);
        ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
        return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
    }
  
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler
    public ErrorResult exHandler(Exception e) {
        log.error("[exHandler] ex]", e);
        return new ErrorResult("EX", "내부 오류");
    }
}
    • ApiExceptionV2Controller 코드에 있는 @ExceptionHandler 는 모두 제거해준다.

@ControllerAdvice

  • @ControllerAdvice 는 대상으로 지정한 여러 컨트롤러에 @ExceptionHandler , @InitBinder 기능을 부여해주는 역할을 한다.
  • @ControllerAdvice 에 대상을 지정하지 않으면 모든 컨트롤러에 적용된다. (글로벌 적용)
  • @RestControllerAdvice 는 @ControllerAdvice 와 같고, @ResponseBody 가 추가되어 있다. @Controller , @RestController 의 차이와 같다.

대상 컨트롤러 지정 방법

  • // Target all Controllers annotated with @RestController
@ControllerAdvice(annotations = RestController.class)
public class ExampleAdvice1 {}
  
// Target all Controllers within specific packages
@ControllerAdvice("org.example.controllers")
public class ExampleAdvice2 {}
  
// Target all Controllers assignable to specific classes
@ControllerAdvice(assignableTypes = {ControllerInterface.class,
AbstractController.class})
public class ExampleAdvice3 {}

댓글남기기

참고