[Spring] 스프링 예외 처리하기

TIlearn 2024. 2. 12. 16:32

스프링의 기본 예외 처리 방법

Spring은 에러 처리를 위해 기본적으로 _BasicErrorConroller_를 구현해 두었다. 그래서 만약 별도로 에러에 관련된 설정을 해두지 않는다면, WAS에서 _/error_로 에러 요청을 다시 보낸다.

그 흐름은 아래와 같다.

_WAS(톰캣)_ ➡️ _필터_ ➡️ _서블릿(DispatcherServlet)_ ➡️ _인터셉터_ ➡️ _컨트롤러_ ➡️ _예외 발생_ ➡️ _인터셉터_ ➡️ _서블릿(DispatcherServlet)_ ➡️ _필터_ ➡️ _WAS(톰캣)_ ➡️ _서블릿(DispatcherServlet)_ ➡️ _인터셉터_ ➡️ _컨트롤러(BasicErrorController)_

중요한 점은 에러를 처리하기 위해 _WAS_로 갔다가 다시한번 컨트롤러를 호출한다는 점이다. 썩 마음에 드는 방식은 아니다.

또한 _BasicErrorContoller_는 기본적으로 _timestamp_, _status_, _path_ 등 응답을 해주지만, 클라이언트의 입장에서 더욱 유용한 응답을 받기 어렵다.

_status_의 경우 WAS에서 에러를 전달받았기에 500으로만 뜬다. 즉, 상황에 적합한 에러를 처리하기 위해서는 별도의 설정이 필요하다.

스프링의 기본 예외 처리 방법

Java에서 예외를 처리하기 위해 _try-catch_문을 사용하는 것이 일반적이지만, 모든 코드에 붙이면 가독성이 떨어지고 비효율적이다.

Spring은 메인 로직으로부터 이러한 예외 처리를 분리하는 것을 원했다. 그래서 예외 처리 전략을 추상화한 _HandlerExceptionResolver_를 고안하게 되었다. (이는 전략 패턴을 사용한 것으로 스프링에서 사용하는 의존성 주입 방식이 이러한 것이다.)

_ HandlerExceptionResolver_은 발생한 예외를 catch 하고 이에 관련된 정보를 설정한다. 그렇게 함으로써 WAS 측으로 예외가 전달되지 않고 WAS 입장에서는 정상적인 동작으로 처리되어 _BasicErrorController_를 요청하지 않는다.

_HandlerExceptionResolver_의 구현체는 총 4가지로 모두 _Bean_으로 등록되어 관리된다.

1️⃣ _DefaultErrorAttributes_ : 직접적으로 에러를 처리하지 않고, 그에 관련된 속성을 저장한다.

2️⃣ _ExceptionHandlerExceptionResolver_ : ControllerAdvice안에 있는 ExceptionHandler 처리

3️⃣ _ResponseStatusExceptionResolver_ : ResponseStatus, ResponseStatusException 처리

4️⃣ _DefaultHandlerExceptionResolver_ : 스프링 내부 기본 예외 처리

속성만을 저장하는 _DefaultErrorAttributes_를 제외한 나머지 _Resolver_에 대해서만 _HandlerExceptionResolverComposite_에서 모아서 관리한다. (컴포지트 패턴 적용)

이렇게 모아진 _ExceptionResolver_를 동작시키게 하기 위해 Spring이 제공하는 도구는 다음과 같다.

1️⃣ _ResponseStatus_

2️⃣ _ResponseStatusException_

3️⃣ _ExceptionHandler_

4️⃣ _ControllerAdvice_, _RestControllerAdvice_

ResponseStatus

_@ResponseStatus_ 어노테이션은 에러에 대한 상태를 변경시켜주는 어노테이션이다. 이전에 WAS까지 갔기에 500으로밖에 처리 못했던 상태를 변경시켜 줄 수 있는 것이다.

적용시켜줄 수 있는 대상으로는 _Exception 클래스_, 메서드에 _@ExceptionHandler_와 같이, 클래스에 @RestControllerAdvice와 함께 사용한다.

하지만 결국에는 WAS로까지 예외가 전달되며 에러에 대한 응답 내용을 변경할 수 없다는 단점이 있다.

ResponseStatusException

예외 클래스와의 결합도를 낮추고, 응답 내용을 직접 프로그래머가 작성할 수 있는 _ResponseStatus_의 대안으로 나온 것이다.

@GetMapping("/product/{id}")
public ResponseEntity<Product> getProduct(@PathVariable String id) {
    try {
        return ResponseEntity.ok(productService.getProduct(id));
    } catch (NoSuchElementFoundException e) {
        throw new ResponseStatusException(HttpStatus.NOT_FOUND, "Item Not Found");
    }
}

하지만 마찬가지로 WAS까지 예외가 전달되며 Spring 내부에서 처리할 수 없다.

ExceptionHandler

가장 많이 사용하는 커스텀 에러 처리 방식이다. 적용할 수 있는 대상은 컨트롤러의 메서드이거나 _@ConrollerAdvice_, 혹은 _@RestControllerAdvice_가 붙은 클래스의 메서드이다.

@RestControllerAdvice
public class GlobalRestControllerAdvice extends ResponseEntityExceptionHandler {

    @ExceptionHandler(ReservationException.class)
    public ResponseEntity<Object> handleInvalidArgument(ReservationException e) {
        ErrorCode errorCode = e.getReservationErrorCode();
        return handleExceptionInternal(errorCode, e.getMessage());
    }

    private ResponseEntity<Object> handleExceptionInternal(ErrorCode errorCode, String message) {
        return ResponseEntity.status(errorCode.getHttpStatus())
                .body(message);
    }
}

위와 같이 _@ExceptionHandler_는 Exception 클래스들을 속성으로 받아서 예외를 지정할 수 있다. 코드를 봐도 알 수 있듯이 응답 내용과 status를 매우 자유롭게 지정해서 사용할 수 있다.

단, 주의할 점은 _@ExceptionHandler_로 등록된 예외 클래스와 메서드의 파라미터로 받는 예외 클래스가 동일해야 한다. 아니면, 런타임 에러가 발생하기 때문이다.

_@ExceptionHandler_의 반환 타입으로는 여러 가지가 올 수 있다. 위 예시는 _ResponseEntity_가 오지만 void, String 등 여러 가지 반환 값이 올 수도 있다.

@ControllerAdvice, @RestControllerAdvice

_@Controller_와 _@RestController_의 차이와 마찬가지로 _@ResponseBody_가 붙어서 json 형식으로 응답을 주는 가에서 차이가 있다.

_@ControllerAdvice_에는 _@Component_ 어노테이션이 붙었기 때문에 스프링 빈으로써 관리된다. 즉, 여러 컨트롤러에 대해서 전역적으로 _ExceptionHandler_를 적용시켜준다.

만약 특정 클래스에만 한정적으로 사용하고 싶다면, _basePackages_등을 설정하여 제한할 수 있다.

Spring에서는 Spring의 예외를 미리 처리해 둔, _ResponseEntityExceptionHandler_라는 추상 클래스가 있다. 예를 들어, 잘못된 URI를 호출했을 경우 이 _ResponseEntityExceptionHandler_를 상속받으면 여기서 처리할 수 있다.

만약 상속받지 않는다면 _DefaultHandlerExceptionResolver_에서 처리하게 되어 일관되지 못한 응답을 받기에 _ResponseEntityExceptionHandler_를 상속시키는 편이 좋다.

그렇다면 예외 처리는?

결국, 3가지의 Resolver 중에서 _ExceptionHandlerExceptionResolver_를 받는 편이 좋다. 결과적으로 WAS까지 예외가 전달되지 않기 때문이다.

따라서 예외 처리 순서도 _ExceptionHandlerExceptionResolver_(_@ExceptionHandler_처리)가 가장 높으며, 그다음으로는 _ResponseStatusExceptionResolver_(_@ResponseStatus_, _ResponseStatusException_처리), _DefaultHandlerExceptionResolver_(기본 예외 처리)가 마지막이다.

ControllerAdvice를 사용한 커스텀 예외 설정

1️⃣ 예외 클래스를 생성해 주자.

package roomescape.common.exception;

import lombok.Builder;
import lombok.Getter;
import lombok.RequiredArgsConstructor;

@Getter
@RequiredArgsConstructor
public class ReservationException extends RuntimeException {

    private ReservationErrorCode reservationErrorCode;
    private String message;

    public ReservationException(ReservationErrorCode reservationErrorCode) {
        this.reservationErrorCode = reservationErrorCode;
        this.message = reservationErrorCode.getMessage();
    }
}

인자로는 에러 코드를 받고 있으며 message도 직접 주입받아 의존도를 낮추었다.

이때, _RuntimeException_(언체크)을 상속받을 것을 볼 수 있다. 이러한 이유는 커스텀으로 설정한 일반적인 비즈니스 로직은 따로 catch 하여 설정해 줄 수 있는 있는 게 없기 때문이며 무분별한 throw를 던지지 않기 때문이다.

또한 Spring은 내부적으로 발생한 예외에서 언체크 예외는 자동으로 롤백하도록 처리한다.

2️⃣ ENUM 클래스 생성

package roomescape.common.exception;

import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.RequiredArgsConstructor;
import org.springframework.http.HttpStatus;


@Getter
@RequiredArgsConstructor
public enum ReservationErrorCode implements ErrorCode {

    INVALID_ARGUMENT_ERROR(HttpStatus.BAD_REQUEST, "필요한 인자가 채워지지 않았습니다."),
    NO_DELETE_RESERVATION_FOUND(HttpStatus.BAD_REQUEST, "삭제할 예약이 없습니다.");

    private final HttpStatus httpStatus;
    private final String message;
}

Exception에 대한 상태 코드와 내용을 미리 생성해 두어, 실제 로직 중에 쉽게 꺼내 쓸 수 있도록 해준다.

3️⃣ _@RestControllerAdvice_ 클래스 추가

이제 전역적으로 에러를 처리해 주기 위해 _@RestControllerAdvice_를 추가해 주자.

package roomescape.common.exception;

import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatusCode;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;
import org.springframework.web.context.request.WebRequest;
import org.springframework.web.servlet.mvc.method.annotation.ResponseEntityExceptionHandler;

@RestControllerAdvice
public class GlobalRestControllerAdvice extends ResponseEntityExceptionHandler {

    @ExceptionHandler(ReservationException.class)
    public ResponseEntity<Object> handleInvalidArgument(ReservationException e) {
        ErrorCode errorCode = e.getReservationErrorCode();
        return handleExceptionInternal(errorCode, e.getMessage());
    }

    private ResponseEntity<Object> handleExceptionInternal(ErrorCode errorCode, String message) {
        return ResponseEntity.status(errorCode.getHttpStatus())
                .body(message);
    }
}

여기서 반환 값에 대한 커스텀을 진행해 줄 수 있다. 이때, 에러 클래스를 만들어 반환 포맷을 설정해 주기도 한다.

4️⃣ 예외 처리하기

@Override
public void deleteReservation(Long id) {
    final String sql = "delete from reservation where id = ?";
    int rowsAffected = jdbcTemplate.update(sql, id);
    if (rowsAffected == 0) {
        throw new ReservationException(ReservationErrorCode.NO_DELETE_RESERVATION_FOUND);
    }
}

이제 등록된 에러 클래스를 통해서 Spring 내부에서 에러를 처리할 수 있게 되었다.