[Spring Boot][5] 8. 예외 처리와 오류 페이지

sorzzzzy·2021년 9월 25일

Spring Springboot TIL

Spring Boot - RoadMap 1

목록 보기

45/46

🏷 프로젝트 생성

스프링 부트 스타터 사이트로 이동해서 프로젝트 생성

✔️ 프로젝트 선택

Project: Gradle
Project Language: Java
Spring Boot: 2.5.x

✔️ Project Metadata

Group: hello
Artifact: exception
Name: exception
Package name: hello.exception
Packaging: Jar
Java: 11

✔️ Dependencies

Spring Web
Lombok
Thymeleaf
Validation

## 🏷 서블릿 예외처리 - 시작

순수 서블릿 컨테이너는 예외를 어떻게 처리할까❓

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

📌 application.properties
server.error.whitelabel.enabled=false
➡️ 스프링 부트가 제공하는 기본 예외 페이지가 있는데 일단 이건 꺼두자!

✔️ ServletExController - 서블릿 예외 컨트롤러

@Slf4j
@Controller
public class ServletExController {

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

실행해보면,
HTTP Status 500 – Internal Server Error
➡️ 이와 같이 톰캣이 기본으로 제공하는 오류 화면을 확인할 수 있다!

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

오류가 발생했을 때 HttpServletResponse 가 제공하는 sendError 라는 메서드를 사용해도 된다!
이것을 호출한다고 당장 예외가 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다😊

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

	@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, "400 오류!");
    }

실행해보면,
HTTP Status 404 – Bad Request
HTTP Status 500 – Internal Server Error
➡️ 서블릿 컨테이너가 기본으로 제공하는 오류 화면을 볼 수 있다!

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

서블릿이 제공하는 오류 화면 기능을 사용해 더 고객 친화적(?)으로 예외처리를 다뤄보자😊

✔️ 서블릿 오류 페이지 등록

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

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

📌 오류 페이지는 예외를 다룰 때 해당 예외와 그 자식 타입의 오류를 함께 처리한다
➡️ 예를 들어서 위의 경우 RuntimeException 은 물론이고 RuntimeException 의 자식도 함께 처리한다.

✔️ 오류 처리 컨트롤러 생성

@Slf4j
@Controller
public class ErrorPageController {

    // get, post 모두 처리하기 위해 @RequestMapping 사용
    @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";
    }

오류 코드에 맞는 View 생성 후, 실행해보면 설정한 오류 페이지가 정상적으로 잘 작동한다👍🏻

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

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

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

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

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

🏷 서블릿 예외처리 - 필터

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

✔️ LogFilter - DispatcherType 로그 추가

로그를 출력하는 부분에 request.getDispatcherType() 을 추가하자.

✔️ WebConfig 수정

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

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

🏷 서블릿 예외처리 - 인터셉터

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

WebConfig

@Override
    // 서블릿 예외 처리 - 인터셉터
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                // 오류 페이지 경로
                .excludePathPatterns("/css/**", "*.ico", "/error", "/error-page/**");
    }

✔️ 전체 흐름 정리

1️⃣ /hello 정상 요청

2️⃣ /error-ex 오류 요청

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

## 🏷 스프링 부트 - 오류 페이지1

지금까지의 과정을 우리의 스프링은! 기본으로 제공하고 있다😊

ErrorPage 를 자동으로 등록한다. 이때 /error 라는 경로로 기본 오류 페이지를 설정한다.
- new ErrorPage("/error") , 상태코드와 예외를 설정하지 않으면 기본 오류 페이지로 사용된다.
- 서블릿 밖으로 예외가 발생하거나, response.sendError(...) 가 호출되면 모든 오류는 /error 를 호출하게 된다.
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, 500처럼 구체적인 것이 5xx처럼 덜 구체적인 것 보다 우선순위가 높다.

✔️ 테스트

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에 담아서 뷰에 전달한다. 뷰 템플릿은 이 값을 활용해서 출력할 수 있다.

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

오류 관련 내부 정보들을 고객에게 노출하는 것은 좋지 않다.
고객이 해당 정보를 읽어도 혼란만 더해지고, 보안상 문제가 될 수도 있기 때문이다☹️
그래서 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 포함 여부

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

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