예외 처리

Single Ko·2023년 6월 4일
0

Spring 강의 정리

목록 보기
19/31

예외

자바 직접 실행

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

웹에서의 예외

웹 애플리캐이션에서는 사용자 요청별로 별도의 쓰레드가 할당되고 서블릿 컨테이너 안에서 실행된다. 이때 애플리케이션에서 예외가 발생했는데, 예외를 잡는다면 문제가 없지만 예외를 잡지 못하고 서블릿 컨테이너 밖으로 예외가 전달 된다면 어떻게 될까?

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

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

이 경우 서버 내부에서 처리할 수 없는 예외가 발생했다 판단해 WAS는 500번대의 오류를 반환하고, 페이지에 오류 화면을 띄우게 된다.

예외 제공 화면

이런 서블릿이 제공하는 기본 예외 처리 화면은 고객친화적이지 않다. 고객이 이런 화면을 본다면 무언가 큰 장애가 났거나 그 서비스에 대해 신뢰감이 떨어질 수 도 있다.

서블릿을 통해 예외 처리 화면 등록

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {

	@Override
 	public void customize(ConfigurableWebServerFactory factory) {
 		ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/errorpage/404");
 		ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
 		ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/errorpage/500");
 		factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
 	}
}
  • response.sendError(404) : errorPage404 호출
  • response.sendError(500) : errorPage500 호출
  • RuntimeException 또는 그 자식 타입의 예외: errorPageEx 호출

예외가 WAS까지 올라갔으면 다시 쭉 예외 페이지를 불러오는 호출을 한다.

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

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

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

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

오류 정보 추가

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

서블릿 예외처리 - 필터

  • 오류가 발생하면 오류 페이지를 출력하기 위해 WAS 내부에서 다시 한번 호출이 발생한다. 이때 필터, 서블릿, 인터셉터도 모두 다시 호출된다. 필터나 인터셉트가 한번 더 호출되는 것은 매우 비효율적이다.

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

DispatcherType

필터는 이런 경우를 위해서 dispatcherTypes 라는 옵션을 제공한다

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 : 서블릿 비동기 호출

필터 클래스 

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

필터 설정에 DispatcherType(REQUEST,ERROR) 두 가지를 모두 넣으면 클라이언트 요청은 물론이고, 오류 페이지 요청에서도 필터가 호출된다.

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

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

  • 인터셉터는 서블릿이 제공하는 기능이 아니라 스프링이 제공하는 기능이다. 따라서
    DispatcherType 과 무관하게 항상 호출된다.

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

전체 흐름 정리

/hello 정상 요청

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

/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

스프링 부트 - 오류 화면 처리

지금까지 예외 처리 페이지를 만들기 위해서 다음과 같은 복잡한 과정을 거쳤다.

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

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

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

개발자는 오류 화면 페이지만 등록하면 됨

  • BasicErrorController 는 기본적인 로직이 모두 개발되어 있다.
  • 개발자는 오류 페이지 화면만 BasicErrorController 가 제공하는 룰과 우선순위에 따라서 등록하면 된다.
  • 정적 HTML이면 정적 리소스, 뷰 템플릿을 사용해서 동적으로 오류 화면을 만들고 싶으면 뷰 템플릿 경로에 오류 페이지 파일을 만들어서 넣어두기만 하면 된다.

뷰 선택 우선순위

BasicErrorController 의 처리 순서

  1. 뷰 템플릿
resources/templates/error/500.html
resources/templates/error/5xx.html
  1. 정적 리소스( static , public )
resources/static/error/400.html
resources/static/error/404.html
resources/static/error/4xx.html
  1. 적용 대상이 없을 때 뷰 이름( error )
resources/templates/error.html

  • 해당 경로 위치에 HTTP 상태 코드 이름의 뷰 파일을 넣어두면 된다.

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

  • 5xx, 4xx 라고 하면 500대, 400대 오류를 처리해준다.

BasicErrorController와 스프링 부트 오류 관련 옵션

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 : 파라미터가 있을 때 사용
server.error.whitelabel.enabled=true 
오류 처리 화면을 못 찾을 시, 스프링 whitelabel 오류 페이지 적용

server.error.path=/error 
오류 페이지 경로, 스프링이 자동 등록하는 서블릿 글로벌 오류 페이지
경로와 BasicErrorController 오류 컨트롤러 경로에 함께 사용된다.

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

정리

오류를 웹 페이지로 해결하는 경우, 고객에게 그냥 페이지를 보여주면 된다. 이런 문제는 쉽게 해결이 가능하다. 실제로 스프링 부트가 많은것을 처리해서 그냥 화면만 만들어 넣으면 되니 엄청 쉽다.

문제는 API로 통신할때 이다. 오류가 생겼을때 웹 페이지처럼 화면만 보여줄 수없다. 오류가 발생했을때 어떻게 오류 메시지를 보내고 정의하는 HTTP API 스펙을 만드는 것은 훨씬 복잡하고 어렵다. 이 방법을 다음에 알아보자.

참고: 본 글은 김영한님의 스프링 강의를 공부하며 정리한 글입니다.

profile
Single Ko
공부 정리 블로그
이전 포스트

필터,인터셉터

다음 포스트

API 예외 처리

0개의 댓글