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

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다.

---

서블릿 예외 처리 - 예외 처리 방식

스프링이 아닌 순수 서블릿 컨테이너는 다음 두 가지 방식으로 예외 처리를 지원한다.

1. Exception(예외)

1-1. 자바의 메인 메서드를 직접 실행하는 경우

실행 도중에 예외를 잡지 못하고 처음 실행한 메인 메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 해당 쓰레드는 종료된다.

1-2. 웹 애플리케이션

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

그런데 만약 애플리케이션 내에서 예외를 잡지 못하고 서블릿 밖으로까지 예외가 전달되면 WAS까지 예외가 전달되고, WAS가 기본으로 제공하는 오류 화면이 나타난다. 이 경우 HTTP 상태 코드가 500을 나타내고 있는데, Exception의 경우 서버 내부에서 처리할 수 없는 오류가 발생한 것으로 판단하기 때문이다.

 

2. sendError()

오류가 발생했을 때 HttpServletResponse가 제공하는 sendError()라는 메서드를 이용할 수도 있는데, HTTP 상태 코드와 오류메시지도 함께 전달할 수가 있다. 해당 메서드를 호출한다고 당장 예외가 발생하는 것은 아니지만 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다. 이후 서블릿 컨테이너는 클라이언트에게 응답을 보내기 전에 sendError() 메서드가 호출되었는지를 확인하고, 호출되었다면 설정한 상태 코드에 맞추어 기본 오류 페이지를 보여준다.

 

 

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

보다 고객 친화적인 예외 처리 화면을 제공하기 위해 서블릿이 지원하는 오류 화면 기능을 이용할 수 있는데, 서블릿은 예외가 발생해서 서블릿 밖으로 전달되거나(앞선 1번 방식) sendError() 메서드가 호출되었을 때(2번 방식) 각각의 상황에 맞춘 오류 처리 기능을 제공한다.

또한 오류 페이지는 예외를 다룰 때 해당 예외와 그 자식 타입의 오류를 함께 처리하는 특징을 가지고 있기도 하다.

 

 

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

서블릿은 오류 코드에 맞는 오류 페이지를 어떻게 찾아서 보여주는 것일까?

서블릿 컨테이너가 지원하는 두 가지 방식으로 예외가 처리될 경우 다음과 같은 흐름을 가진다.(공통적으로 WAS까지 오류 전달)

1. Exception
WAS(여기까지 전달) ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러(예외 발생)

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

WAS는 해당 예외를 처리하는 오류 페이지 정보를 확인하고, 페이지를 출력하기 위해 내부적으로 해당 경로를 호출한다. 뿐만 아니라 오류 정보를 HttpServletRequest의 attribute에 추가해서 넘겨준다.(예외, 예외타입, 오류 메시지, 클라이언트 요청 URI, 오류가 발생한 서블릿 이름, HTTP 상태 코드)

이렇게 함으로써 필요할 경우 전달된 오류 정보를 오류 페이지에서 사용할 수 있다. 그렇게 오류 페이지 경로를 호출하면 해당 경로로 필터, 서블릿, 인터셉터, 컨트롤러 또한 다시 호출된다. 여기서 중요한 것은 클라이언트에서는 서버에서 해당 과정을 통해 오류 페이지를 찾는다는 것을 모른다는 점인데, 오직 서버 내부에서 오류 페이지를 찾기 위해 추가적인 호출을 한다.

 

 

서블릿 예외 처리 - 필터

앞서 언급했듯이 오류 페이지 경로를 호출하는 과정에서 필터, 서블릿, 인터셉터가 모두 다시 호출되는데 이미 일차적으로 검증이 완료된 상태이기 때문에 오류 페이지를 호출할 때 한번 더 검증 단계를 거치는 것은 비효율적이다.

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

/**
FORWARD - 다른 서블릿이나 JSP를 호출할 때
INCLUDE - 다른 서블릿이나 JSP의 결과를 포함할 때
REQUEST - 클라이언트 요청
ASYNC - 서블릿 비동기 호출
ERROR - 오류 요청
*/
public enum DispatcherType {     
    FORWARD,    
    INCLUDE,     
    REQUEST,     
    ASYNC,     
    ERROR
}

 

필터를 등록하는 과정에서 FilterRegistrationBean<T>.setDispatcherTypes()을 통해 타입을 지정해 넣으면, 해당 타입에 해당되는 경우에만 필터가 호출된다.(기본 값은 DispatcherType.REQUEST)

기본 값으로 지정해 두면 클라이언트로부터 발생한 정상 요청의 경우에만 필터가 호출되어 추가적인 호출이 없어진다.

 

 

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

앞서 필터의 경우 필터를 등록할 때 어떤 DispatcherType인지 타입을 나누어 필터 적용 여부를 선택할 수 있었지만, 인터셉터는 서블릿이 제공하는 기능이 아닌 스프링이 제공하는 기능이기 때문에 DispatcherType과 무관하게 항상 호출된다.

대신 인터셉터는 요청 경로를 추가하거나 제외하기가 쉽기 때문에 InterceptorRegistry.excludePathPatterns() 메서드를 이용한 설정을 통해 오류 페이지 경로를 제외해 주면 인터셉터가 호출되지 않는다.

 

 

스프링 부트 - BasicErrorController

기존에는 예외 처리 페이지를 만들기 위해 WebServerCustomizer를 만들고, 예외 종류에 따라서 에러 페이지를 추가하고, 예외 처리용 컨트롤러를 만드는 복잡한 과정을 거쳐야 한다.

 

하지만 스프링 부트는 이러한 과정을 모두 기본으로 제공해 주는데,

1. 우선 에러 페이지를 /error라는 경로로 자동 등록해 준다. 만약 서블릿 밖으로 예외가 발생하거나 sendError() 메서드가 호출되면 모든 오류는 기본적으로 /error를 호출한다.

2. 에러 페이지에서 등록한 /error를 맵핑해서 처리하는 컨트롤러인 BasicErrorController라는 스프링 컨트롤러를 자동으로 등록한다. 해당 컨트롤러는 기본적인 로직이 모두 개발되어 있기 때문에, 개발자는 오류 페이지 화면만 BasicErrorController가 제공하는 규칙과 우선순위에 따라서 등록하면 된다. 우선순위는 다음과 같다.

1. 뷰 템플릿
- resources/templates/error/500.html 

2. 정적 리소스(static, public)
- resources/static/error/4xx.html

3. 적용 대상이 없을 경우 뷰 이름(error)
- resources/templates/error.html

 

 

스프링 부트 - BasicErrorController 제공 정보

BasicErrorController는 다음 정보를 모델에 담아서 뷰에 전달하기 때문에, 뷰 템플릿은 전달되는 정보를 활용해 출력할 수 있다.

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

하지만 오류 관련 내부 정보들을 클라이언트에게 노출할 경우 혼란만 더해질 뿐 아니라 어떤 라이브러리를 사용하는지 파악해서 약점을 파고드는 등의 보안 상 문제가 발생할 수 있기 때문에, 위의 오류 정보들을 모델에 포함할지 여부를 선택할 수 있다.

(실무에서 노출 X, 서버 로그 기록 용도로만 사용)

#application.properties에 추가
#세 가지 옵션 존재; 'never(사용 X)', 'always(항상 사용)', 'on_param(파라미터가 있을 때 사용)'
server.error.include-exception=true #exception 포함 여부
server.error.include-message=on_param #message 포함 여부
server.error.include-stacktrace=on_param #trace 포함 여부
server.error.include-binding-errors=on_param #errors 포함 여부