[Spring MVC] API 예외 처리 - ExceptionResolver(Spring)
ExceptionResolver
스프링 부트가 기본으로 제공하는 ExceptionResolver
ExceptionHandlerExceptionResolver
ResponseStatusExceptionResolver
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)으로 변경하고, 메시지도 담는다.
메시지 기능
reason
을 MessageSource
에서 찾는 기능도 제공한다. 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편 - 백엔드 웹 개발 활용 기술(김영한)>
댓글남기기