@Slf4j
public class MyHandlerExceptionResolver implements HandlerExceptionResolver {
@Override
public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
try {
if (ex instanceof IllegalArgumentException) {
log.info("IllegalArgumentException resolver to 400");
response.sendError(HttpServletResponse.SC_BAD_REQUEST, ex.getMessage());
return new ModelAndView();
}
} catch (IOException e) {
log.error("resolver ex", e);
}
return null;
}
}
IllegalArgumentException 이 발생하면 response.sendError(400) 를 호출해서 HTTP 상태 코드를 400으로 지정하고, 빈 ModelAndView 를 반환한다.
반환값에 따라 동작방식이 다르다. -> DispatcherServlet의 동작방식은 아래와 같다.
return 빈 ModelAndView : ew ModelAndView() 처럼 빈 ModelAndView 를 반환하면 뷰를 렌더링 하지 않고, 정상 흐름으로 서블릿이 리턴된다.
return ModelAndView 지정 : ModelAndView 에 View , Model 등의 정보를 지정해서 반환하면 뷰를 렌더링 한다.
return null : null 을 반환하면, 다음 ExceptionResolver 를 찾아서 실행한다. 만약 처리할 수 있는 ExceptionResolver 가 없으면 예외 처리가 안되고, 기존에 발생한 예외를 서블릿 밖으로 던진다.
HandlerExceptionResolver 활용
위와 같이처리하면 WAS에서 오류메시지를 찾아서 다시 처리하는 과정이 필요하다.
그런 과정없이 딱 HandlerExceptionResolver에서 오류를 모두 처리하려면 아래와 같은 과정이 필요하다.
@Slf4j
public class UserHandlerExceptionResolver implements HandlerExceptionResolver {
private final ObjectMapper objectMapper = new ObjectMapper();
@Override
public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
try {
if (ex instanceof UserException) {
log.info("UserException resolver to 400");
String acceptHeader = request.getHeader("accept");
response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
if ("application/json".equals(acceptHeader)) {
Map<String, Object> errorResult = new HashMap<>();
errorResult.put("ex", ex.getClass());
errorResult.put("message", ex.getMessage());
String result = objectMapper.writeValueAsString(errorResult);
response.setContentType("application/json");
response.setCharacterEncoding("utf-8");
response.getWriter().write(result);
return new ModelAndView();
} else {
//TEXT/HTML
return new ModelAndView("error/500");
}
}
} catch (IOException e) {
log.error("resolver ex", e);
}
return null;
}
}
위와 같이 구현하면 UserException으로 오류가 넘어온 경우 response에 내용을 세팅해줌으로써 오류를 해결할 수 있다.
컨트롤러에서 예외가 발생해도 ExceptionResolver 에서 예외를 처리해버린다.
따라서 예외가 발생해도 서블릿 컨테이너까지 예외가 전달되지 않고, 스프링 MVC에서 예외 처리는 끝이난다.
결과적으로 WAS 입장에서는 정상 처리가 된 것이다. 이렇게 예외를 이곳에서 모두 처리할 수 있다는 것이 핵심이다.
서블릿 컨테이너까지 예외가 올라가면 복잡하고 지저분하게 추가 프로세스가 실행된다. 반면에 ExceptionResolver 를 사용하면 예외처리가 상당히 깔끔해진다.
하지만 여전히 값을 세팅해주는 과정이 복잡하고 번거롭다.
스프링이 제공하는 ExceptionResolver 들을 사용하면 더 간단하게 구현할 수 있다.
스프링이 제공하는 ExceptionResolver
스프링 부트가 기본으로 제공하는 ExceptionResolver 는 아래와 같다.
ExceptionHandlerExceptionResolver -> 1순위
@ExceptionHandler 을 처리한다. API 예외 처리는 대부분 이 기능으로 해결한다.
ResponseStatusExceptionResolver -> 2순위
HTTP 상태 코드를 지정해준다.
ex> @ResponseStatus(value = HttpStatus.NOT_FOUND)
DefaultHandlerExceptionResolver -> 3순위
스프링 내부 기본 예외를 처리한다.
위와 같은 순위로 HandlerExceptionResolverComposite 에 등록된다.
ResponseStatusExceptionResolver (스프링이 제공하는 ExceptionResolver 2순위)
@ResponseStatus 가 달려있는 예외
구현은 아래와 같이 할 수 있다.
@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "잘못된 요청 오류")
public class BadRequestException extends RuntimeException {
}
- BadRequestException 예외가 컨트롤러 밖으로 넘어가면 -> ResponseStatusExceptionResolver 예외가 해당 애노테이션을 확인해서 오류 코드를 HttpStatus.BAD_REQUEST (400)으로 변경하고, 메시지도 담는다.
- 결국 response.sendError(statusCode, resolvedReason) 를 호출하는 방식으로 처리된다.
- response.sendError(HttpStatus.BAD_REQUEST, "잘못된 요청 오류") 이렇게 넘어간다.
- sendError(400) 를 호출했기 때문에 WAS에서 다시 오류 페이지( /error )를 내부 요청한다.
- 결국 WAS로 가기전에 완전히 에러를 처리하는 방식은 아니다.
ResponseStatusException 예외
ResponseStatus 는 개발자가 직접 변경할 수 없는 예외에는 적용할 수 없다.
추가로 애노테이션을 사용하기 때문에 조건에 따라 동적으로 변경하는 것도 어렵다. 이때는 ResponseStatusException 예외를 사용하면 된다.
@GetMapping("/api/response-status-ex2")
public String responseStatusEx2() {
throw new ResponseStatusException(HttpStatus.NOT_FOUND, "error.bad", new IllegalArgumentException());
}
IllegalArgumentException 에러의 경우엔 HttpStatus.NOT_FOUND 로 처리할 수 있다.
DefaultHandlerExceptionResolver (스프링이 제공하는 ExceptionResolver 3순위)
DefaultHandlerExceptionResolver 는 스프링 내부에서 발생하는 스프링 예외를 해결한다.
대표적으로 파라미터 바인딩 시점에 타입이 맞지 않으면 내부에서 TypeMismatchException 이 발생한다.
이 경우 예외가 발생했기 때문에 그냥 두면 서블릿 컨테이너까지 오류가 올라가고, 결과적으로 500 오류가 발생한다.
하지만 HTTP 에서는 이런 경우 HTTP 상태 코드 400을 사용하도록 되어 있다.
그 이유는 스프링에서 제공하는 DefaultHandlerExceptionResolver가 response.sendError(HttpServletResponse.SC_BAD_REQUEST)을 통해서 500에러를 400에러로 처리해주기 때문이다.
하지만 여전히 API 오류 응답의 경우에 response 에 직접 데이터를 넣어야 해서 매우 불편하고 번거롭다.
이러한 문제를 해결하기 위해서 실무에서 가장 많이 쓰이는 ExceptionHandlerExceptionResolver를 제공한다.
1. 컨트롤러를 호출한 결과 IllegalArgumentException 예외가 컨트롤러 밖으로 던져진다. 예외가 발생했으로 ExceptionResolver 가 작동한다. 가장 우선순위가 높은 ExceptionHandlerExceptionResolver 가 실행된다.
2. ExceptionHandlerExceptionResolver 는 해당 컨트롤러에 IllegalArgumentException 을 처리할 수 있는 @ExceptionHandler 가 있는지 확인한다.
3. illegalExHandle() 를 실행한다. @RestController 이므로 illegalExHandle() 에도 @ResponseBody 가 적용된다. 따라서 HTTP 컨버터가 사용되고, 응답이 다음과 같은 JSON으로 반환된다.
4. @ResponseStatus(HttpStatus.BAD_REQUEST) 를 지정했으므로 HTTP 상태 코드 400으로 응답한다.
에러가 발생하고 WAS 로 에러가 전달되기 전에 ExceptionHandlerExceptionResolver가 에러를 처리하고 에러메시지를 전달한다.
response.sendError(HttpServletResponse.SC_BAD_REQUEST, ex.getMessage()) 와의 차이를 기억해야한다.
response.sendError(HttpServletResponse.SC_BAD_REQUEST, ex.getMessage()) 는 에러가 WAS 까지 전달되고 다시 컨트롤러까지 에러를 포함한 요청이 다시 요청된다.
하지만 해당 클래스 안에서 선언한 @ExceptionHandler는 해당 클래스 안에 있는 컨트롤러에서만 적용된다.
원하는 컨트롤러에 모두 적용하기 위해서는 @ControllerAdvice 또는 @RestControllerAdvice 를 사용할 수 있다.
@ControllerAdvice
@ControllerAdvice 를 사용하면 원하는 컨트롤러에 @ExceptionHandler를 반영시킬 수 있다.
구현은 아래와 같이 할 수 있다.
@Slf4j
@RestControllerAdvice
public class ExControllerAdvice {
@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", "내부 오류");
}
}
@ControllerAdvice 는 대상으로 지정한 여러 컨트롤러에 @ExceptionHandler , @InitBinder 기능을 부여해주는 역할을 한다.
@ControllerAdvice 에 대상을 지정하지 않으면 모든 컨트롤러에 적용된다. (글로벌 적용)
컨트롤러를 아래와 같이 지정할 수 있다.
// Target all Controllers annotated with @RestController
@ControllerAdvice(annotations = RestController.class)
public class ExampleAdvice1 {}
// Target all Controllers within specific packages
@ControllerAdvice("org.example.controllers")
public class ExampleAdvice2 {}
// Target all Controllers assignable to specific classes
@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})
public class ExampleAdvice3 {}
RestController 로 구현된 모든 컨트롤러에 반영할 수도 있다.
패키지로 지정할 수도 있다.
클래스를 지정해서 상속받은 모든 컨트롤러에 반영시킬 수도 있다.
결론
@ExceptionHandler 와 @ControllerAdvice 를 조합하면 예외를 깔끔하게 해결할 수 있다.
