"exception" 태그로 연결된 1개 게시물개의 게시물이 있습니다.

Intro​

자바 프로그램에서 예외가 발생하면 스레드가 종료됩니다. 하지만 스프링에서는 예외가 발생해도 어플리케이션이 종료되지 않고, 예외 응답을 반환합니다. 스프링은 어떻게 예외를 처리하기에 이렇게 작동하는 것일까요?🤔 이번 글에서는 스프링에서 어떻게 예외를 처리하는지와, 어떻게해야 예외를 잘~ 처리할 수 있는지 알아보겠습니다.

🔍 스프링의 기본 예외 처리 방식​

어떠한 예외처리도 하지 않았을 때, 스프링에서 어떤식으로 예외가 처리될까요? 우선 스프링의 기본 작동 방식에 대해 생각해봅시다. 스프링에 요청이 오면, WAS - Dispatcher Servlet - HandlerMapping - HandlerAdapter - Controller 를 거쳐 로직이 실행됩니다.

이때 예외가 발생하면 예외 내용은 WAS까지 거슬러 올라갑니다. 그럼 WAS는 어플리케이션에서 처리할 수 없는 예외라 판단하여 에러 컨트롤러로 예외 내용을 전달합니다. 즉, 예외가 발생하면 WAS - Controller - WAS - ErrorController 의 흐름을 갖게 됩니다. 이 과정을 통해 예외가 발생해도 어플리케이션을 종료하지 않고, 마치 정상 요청인 것처럼 예외 응답을 반환하는 것입니다.

BasicErrorController​

이때 호출되는 에러 컨트롤러가 바로 BasicErrorController 입니다. 실제로 어떠한 예외처리도 하지 않고 BasicErrorController에 BreakPoint 를 걸어두고 디버깅하니, BasicErrorController에서 예외가 핸들링되는 것을 확인할 수 있었습니다.

BasicErrorController의 응답​

BasicErrorController는 DefaultErrorAttributes의 getErrorAttributes() 함수를 호출해서 응답할 내용을 불러옵니다. 이때 getErrorAttributes()가 기본적으로 제공하는 속성과, 설정을 통해 추가할 수 있는 속성들은 다음과 같습니다.

• timestamp: 에러가 발생한 시간
• status: 에러의 Http 상태
• error: 에러 코드
• path: 에러가 발생한 uri
• exception: 최상위 예외 클래스의 이름(설정 필요)
• message: 에러에 대한 내용(설정 필요)
• errors: BindingExecption에 의해 생긴 에러 목록(설정 필요)
• trace: 에러 스택 트레이스(설정 필요)

// 어떤 설정도 하지 않았을 때의 응답
{
    "timestamp": "2024-07-21T16:16:40.463+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "path": "/reviews/999"
}

// 추가할 수 있는 속성들
server:
  error:
    include-message: always
    include-binding-errors: always
    include-stacktrace: always
    include-exception: true

// 모든 속성을 추가했을 때의 응답
{
    "timestamp": "2024-07-21T16:19:58.729+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "exception": "org.springframework.orm.jpa.JpaObjectRetrievalFailureException",
    "trace": "org.springframework.orm.jpa.JpaObjectRetrievalFailureException\n\tat ….",
    "message": "No message available",
    "path": "/reviews/999"
}

BasicErrorController를 통한 예외 처리의 한계​

혹시 '이것만으로도 충분히 훌륭한데?' 라는 생각이 드시나요? 하지만 이 방식에는 몇가지 한계가 존재합니다. 첫째로, 이 방식은 WAS에서 컨트롤러를 거쳐, 다시 WAS로 왔다가, 에러 컨트롤러로 가는 흐름인데요, 이 과정이 길고 복잡하게 느껴집니다. 또 이는 필터나 인터셉터를 2번 호출하는 등 다른 문제를 야기할 수 있습니다. 그리고 결정적으로, 예외에 따라 다른 HttpStatusCode와 메세지를 줄 수도 없습니다😓

🔍 스프링이 제공하는 다양한 예외 처리 방식​

이런 단점을 보완하기 위해서, 스프링에서는 기본 예외 처리 외에도 다양한 예외 처리 방식을 제공합니다.

HandlerExceptionResolver​

HandlerExceptionResolver는 예외 처리 방식을 추상화한 인터페이스입니다. 이를 구현하는 구현체들은 발생한 예외를 캐치하여 응답의 Http 상태나 메세지를 설정합니다.

HandlerExceptionResolver의 구현체들​

HandlerExceptionResolver의 구현체들은 HandlerExceptionResolverComposite에 우선순위 순서대로 빈으로 등록되어 관리됩니다.

그리고 예외 발생 시, 우선순위 순으로 구현체들을 순회하며 핸들링을 할 수 있는지 확인합니다.

public class HandlerExceptionResolverComposite implements HandlerExceptionResolver, Ordered {

	@Override
	@Nullable
	public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {
		if (this.resolvers != null) {
                        // 구현체들을 순회하면서 예외를 처리할 수 있는지 확인
			for (HandlerExceptionResolver handlerExceptionResolver : this.resolvers) {
				ModelAndView mav = handlerExceptionResolver.resolveException(request, response, handler, ex);
				if (mav != null) {
					return mav;
				}
			}
		}
		return null;
	}
}

빈으로 등록된 HandlerExceptionResolver 구현체과 그것이 처리하는 대상은 아래와 같습니다.

• ExceptionHandlerExceptionResolver : ExceptionHandler를 처리
• ResponseStatusExceptionResolver : ResponseStatus, ResponseStatusException를 처리
• DefaultHandlerExceptionResolver : 스프링 내부의 기본 예외들을 처리

하지만 ResponseStatusExceptionResolver 만으로는 에러 응답을 수정할 수 없으며, 일괄 에러 처리를 할 수 없다는 단점이 있으므로 이번 글에서는 설명하지 않겠습니다.

🔍 HandlerExceptionResolver를 동작시키는 것들​

@ExceptionHandler와 @ControllerAdvice​

@ExceptionHandler는 가장 우선순위가 높은 예외 핸들러인 ExceptionHandler ExceptionResolver에서 처리됩니다. @ExceptionHandler는 예외 응답의 코드와 메세지를 자유롭게 설정할 수 있다는 장점이 있습니다. @ExceptionHandler는 컨트롤러의 메서드에 바로 사용할 수도 있으며, @ControllerAdvice나 @RestControllerAdvice가 있는 클래스의 메소드에도 사용할 수 있습니다. 만약 컨트롤러의 메서드에도 @ExceptionHandler를 사용하고, @ControllerAdvice에도 사용한다면 전자가 우선시됩니다.

스프링 내부의 기본 예외들​

스프링에서 발생할 수 있는 기본 예외들은 미리 정의되어, DefaultHandler ExceptionResolver에서 처리됩니다. 대표적인 예외로는 지원하지 않는 HttpMethod 로 요청을 보낼 때 발생하는 HttpRequestMethod NotSupportedException가 있습니다. DefaultHandler ExceptionResolver는 에러를 핸들링해서 어떤 기본 예외인지 판별하는 역할까지만 하므로, 직접 예외 응답을 반환하지는 않습니다. 따라서 최종적으로 BasicController를 통해서 예외 응답을 반환합니다.

ResponseEntityExceptionHandler​

여기까지 읽으시며 이상함을 느끼셨나요?😳 ExceptionHandler를 사용하면 예외 응답 형식을 지정할 수 있습니다. 반면 스프링 기본 예외는 DefaultHandler ExceptionResolver로 처리되기 때문에 BasicController의 응답 형식을 따르게 됩니다. 따라서 ExceptionHandler로 처리되는 예외와, 기본 예외의 응답 형식이 다르다는 문제가 생기게 됩니다. 이를 해결하기 위해 스프링은 ResponseEntity ExceptionHandler 를 제공합니다.

ResponseEntity ExceptionHandler는 스프링 기본 예외에 대한 핸들링을 미리 정의해둔 추상 클래스입니다. 따라서 ControllerAdvice가 ResponseEntity ExceptionHandler를 상속하게 하는것 만으로 스프링 기본 예외를 핸들링할 수 있습니다. 또한 ResponseEntity ExceptionHandler는 모든 기본 예외를 handleExceptionInternal() 함수로 처리하고 있기 때문에, 이 함수를 오버라이딩해줌으로써, 모든 기본 예외의 응답을 커스텀 예외 응답형식으로 통일할 수 있습니다.

어떻게 해야 예외를 잘 응답할 수 있을까?​

여기까지 우리는 스프링에서 예외를 처리하는 방법에 대해 알아봤습니다. 그럼 이들을 바탕으로 우리는 어떻게 예외를 잘 처리하고, 잘 응답할 수 있을까요?🤔 제가 세운 기준은 아래와 같습니다.

1. ExceptionHandler를 사용하자.​

스프링의 기본 예외 처리 방식인 BasicErrorController 를 사용하는 방식은, http status code 와 예외 메세지를 지정할 수 없다는 문제가 있습니다. ExceptionHandler 를 사용해서 유연하게 예외를 핸들링하는 것이 좋습니다.

2. ControllerAdvice 안에서 ExceptionHandler를 사용하자.​

ExceptionHandler를 사용해서 각 컨트롤러마다 예외를 처리하는 방식은 중복되는 코드가 많을 것입니다. 또한 어떤 컨트롤러에는 ExceptionHandler를 붙이고, 다른 컨트롤러에는 붙이지 않는 등의 누락도 생길 수 있습니다. 따라서 예외 핸들링을 전역으로 할 수 있는 ControllerAdvice 안에서 ExceptionHandler를 사용하는 것이 좋습니다.

3. 최상위 예외인 Exception를 핸들링하자.​

최상위 예외에 대한 핸들링을 하지 않는다면, BasicController 를 통해 응답되는 예외가 있을 수 있습니다. 그렇다면 우리가 정의한 커스텀 예외 응답과 다른 형식이 되므로, 일관성이 깨지게 됩니다. 따라서 최상위 예외에 대해 처리를 해줘야 합니다.

4. 스프링 기본 예외의 응답을 통일하자.​

마찬가지로 일관성을 위해 스프링 기본 예외의 응답도 통일할 필요가 있습니다. 따라서 ControllerAdvice에서 ResponseEntityExceptionHandler를 상속하고, handleExceptionInternal() 함수를 오버라이딩해줘야 합니다.