3 분 소요


ExceptionResolver

스프링 부트가 기본으로 제공하는 ExceptionResolver

  1. ExceptionHandlerExceptionResolver
  2. ResponseStatusExceptionResolver
  3. DefaultHandlerExceptionResolver -> 우선 순위가 가장 낮음

ExceptionHandlerExceptionResolver
@ExceptionHandler을 처리. API 예외 처리는 대부분 이 기능으로 해결.

ResponseStatusExceptionResolver
HTTP 상태 코드를 지정해준다.
Ex) @ResponseStatus(HttpStatus.NOT_FOUND)

DefaultHandlerExceptionResolver
스프링 내부 기본 예외를 처리.


ResponseStatusExceptionResolver

ResponseStatusExceptionResolver는 예외에 따라서 HTTP 상태 코드를 지정해주는 역할을 한다.

다음 두 가지 경우를 처리한다.

  • @ResponseStatus가 달려있는 예외
  • ResponseStatusException 예외

@ResponseStatus

ApiExceptionController

@GetMapping("/api/response-status-ex1")
public String responseStatusEx1() {
    throw new BadRequestException();
}

예외에 @ResponseStatus 애노테이션을 적용하면 HTTP 상태 코드를 변경해준다.

@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "잘못된 요청 오류")
public class BadRequestException extends RuntimeException {
}

BadRequestException예외가 컨트롤러 밖으로 넘어가면 ResponseStatusExceptionResolver 예외가 해당 애노테이션을 확인해서 오류 코드를 HttpStatus.BAD_REQUEST(400)으로 변경하고, 메시지도 담는다.

메시지 기능

reasonMessageSource에서 찾는 기능도 제공한다. reason = "error.bad"

messages.properties

error.bad=잘못된 요청 오류입니다.

@ResponseStatus는 개발자가 직접 수정할 수 없는 예외에는 적용할 수 없다.(애노테이션을 직접 넣어야 하는데, 코드를 수정할 수 없는 라이브러리 예외 코드 같은 곳에는 적용할 수 없다.)
이때는 ResponseStatusException예외를 사용하면 된다.

ResponseStatusException

ApiExceptionController

@GetMapping("/api/response-status-ex2")
public String responseStatusEx2() {
    throw new ResponseStatusException(
        HttpStatus.NOT_FOUND, "error.bad", new IllegalArgumentException());
}


DefaultHandlerExceptionResolver

DefaultHandlerExceptionResolver는 스프링 내부에서 발생하는 스프링 예외를 해결한다.
대표적으로 파라미터 바인딩 시점에 타입이 맞지 않으면 TypeMismatchException이 발생하는데, 결과적으로 500오류가 발생한다.
그런데 파라미터 바인딩은 대부분 클라이언트가 요청 정보를 잘못 호출해서 발생하는 문제이기 때문에, DefaultHandlerExceptionResolver는 이것을 500오류가 아닌 HTTP 상태코드 400오류로 변경한다.

코드 확인

DefaultHandlerExceptionResolver.handleTypeMismatch를 보면 다음 코드를 확인할 수 있다.
response.sendError(HttpServletResponse.SC_BAD_REQUEST)(400)

sendError(400)를 호출했기 때문에 WAS에서 다시 오류 페이지(/error)를 내부 요청한다.

ApiExceptionController

@GetMapping("/api/default-handler-ex")
public String defaultException(@RequestParam Integer data) {
    return "ok";
}

Integer data에 문자를 입력하면 내부에서 TypeMismatchException이 발생한다.

실행 결과를 보면 HTTP 상태 코드가 400으로 되어있다.

정리

  • ResponseStatusExceptionResolver -> HTTP 응답 코드 변경
  • DefaultHandlerExceptionResolver -> 스프링 내부 예외 처리


ExceptionHandlerExceptionResolver

HTML 화면 오류 Vs API 오류
웹 브라우저에 HTML 화면을 제공할 때 오류가 발생하면 BasicErrorController를 사용하는게 편하다.

API는 각 시스템 마다 응답의 모양도 다르고, 스펙도 모두 다르기 때문에 예외에 따라서 각각 다른 데이터를 출력해야 할 수도 있다. BasicErrorController를 사용하거나 HandlerExceptionResolver를 직접 구현하는 방식으로 API 예외를 다루기는 쉽지 않다.

API 예외처리의 어려운 점

  • HandlerExceptionResolver를 보면 ModelAndView를 반환해야 했는데, API 응답에는 필요하지 않다.
  • API 응답을 위해서 HttpServletResponse에 직접 응답 데이터를 하나하나 넣어주었다.
  • 특정 컨트롤러에서만 발생하는 예외를 별도로 처리하기 어렵다.
    • 회원을 처리하는 컨트롤러에서 발생하는 RuntimeException 예외와 상품을 관리하는 컨트롤러에서 발생하는 동일한 RuntimeException예외를 다른 방식으로 처리하고 싶다.

@ExceptionHandler

스프링은 API 예외 처리 문제를 해결하기 위해 @ExceptionHandler애노테이션을 사용하는 편리한 예외 처리 기능을 제공하는데, 이것이 ExceptionHandlerExceptionResolver이다.
스프링이 기본으로 제공하는 ExceptionResolver중에 우선 순위가 가장 높다.
실무에서 API 예외 처리는 대부분 이 기능을 사용!

ErrorResult

@Data
@AllArgsConstructor
public class ErrorResult {
    private String code;
    private String message;
}

예외가 발생했을 때 API 응답으로 사용하는 객체를 정의.

ApiExceptionV2Controller

@Slf4j
@RestController
public class ApiExceptionV2Controller {

    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(IllegalArgumentException.class)
    public ErrorResult illegalExHandle(IllegalArgumentException e) {
        log.error("[exceptionHandle] ex", e);
        return new ErrorResult("BAD", e.getMessage());
    }

    @ExceptionHandler
    public ResponseEntity<ErrorResult> userExHandle(UserException e) {
        log.error("[exceptionHandle] ex", e);
        ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
        return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
    }

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler
    public ErrorResult exHandle(Exception e) {
        log.error("[exceptionHandle] ex", e);
        return new ErrorResult("EX", "내부 오류");
    }

    @GetMapping("/api2/members/{id}")
    public MemberDto getMember(@PathVariable("id") String id) {
        if (id.equals("ex")) {
            throw new RuntimeException("잘못된 사용자");
        }

        if (id.equals("bad")) {
            throw new IllegalArgumentException("잘못된 입력 값");
        }
        
        if (id.equals("user-ex")) {
            throw new UserException("사용자 오류");
        }
        //return 생략...
    }

}

IllegalArgumentException 실행 흐름

  • 컨트롤러를 호출한 결과 IllegalArgumentException예외가 컨트롤러 밖으로 던져진다.
  • 예외가 발생했으므로 ExceptionResolver가 동작하는데, 우선순위가 가장 높은 ExceptionHandlerExceptionResolver가 실행된다.
  • ExceptionHandlerExceptionResolver는 해당 컨트롤러에 IllegalArgumentException을 처리할 수 있는 @ExceptionHandler가 있는지 확인.
  • illegalExHandle()를 실행.
    • @RestController이므로 illegalExHandle()에도 @ResponseBody가 적용된다. 따라서, HTTP 컨버터가 사용되고, 응답이 JSON으로 반환된다.
  • @ResponseStatus(HttpStatus.BAD_REQUEST)를 지정했으므로 HTTP 상태 코드 400으로 응답한다.

실행 결과

{
    "code": "BAD",
    "message": "잘못된 입력 값"
}

@ExceptionHandler 예외 처리 방법
@ExceptionHandler 애노테이션을 선언하고, 해당 컨트롤러에서 처리하고 싶은 예외를 지정해주면 된다. 해당 컨트롤러에서 예외가 발생하면 이 메서드가 호출된다.
참고로 지정한 예외 또는 그 예외의 자식 클래스는 모두 잡을 수 있다.

ResponseEntity
메시지 바디에 직접 출력하기 위해 사용했고, return시 객체와 함께 상태 코드를 넣어주면 응답 결과를 볼때 실제 주입한 상태 코드가 적용된다.

우선순위

@ExceptionHandler(부모예외.class)
public String 부모예외처리()(부모예외 e) {}

@ExceptionHandler(자식예외.class)
public String 자식예외처리()(자식예외 e) {}

@ExceptionHandler에 지정한 부모 클래스는 자식 클래스까지 처리할 수 있다.
그런데 둘 중 더 자세한 것이 우선권을 가지므로 자식예외처리()가 우선적으로 호출된다.

다양한 예외

다양한 예외를 한번에 처리할 수 있다.

@ExceptionHandler({AException.class, BException.class})
public String ex(Exception e) {
    log.info("exception e", e);
}

예외 생략

@ExceptionHandler의 예외를 생략하면 메서드 파라미터의 예외가 지정된다.

@ExceptionHandler
public ResponseEntity<ErrorResult> userExHandle(UserException e) {}

기타

HTML 오류 화면

@ExceptionHandler(ViewException.class)
public ModelAndView ex(ViewException e) {
    log.info("exception e", e);
    return new ModelAndView("error");
}

ModelAndView를 사용해서 오류 화면(HTML)을 응답하는데 사용할 수도 있다.


<출처 : 인프런 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술(김영한)>

댓글남기기