본 내용은 인프런 김영한님의
"스프링 MVC 2편 - 백엔드 웹 개발 활용 기술" 강의 내용을 정리한 것입니다.
📕 API 예외 처리
API의 경우에는 생각할 내용이 더 많다. 오류 페이지는 단순히 고객에게 오류 화면을 보여주고
끝이지만, API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려주어야 한다.
[ApiExceptionController] - API 예외 컨트롤러
@Slf4j
@RestController
public class ApiExceptionController {
@GetMapping("/api/members/{id}")
public MemberDto getMember(@PathVariable("id") String id) {
if (id.equals("ex")) {
throw new RuntimeException("잘못된 사용자");
}
return new MemberDto(id, "hello " + id);
}
@Data
@AllArgsConstructor
static class MemberDto {
private String memberId;
private String name;
}
}
[ErrorPageController] - API 응답 추가
@RequestMapping(value = "/error-page/500", produces = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<Map<String, Object>> errorPage500Api(
HttpServletRequest request, HttpServletResponse response) {
log.info("API errorPage 500");
Map<String, Object> result = new HashMap<>();
Exception ex = (Exception) request.getAttribute(ERROR_EXCEPTION);
result.put("status", request.getAttribute(ERROR_STATUS_CODE));
result.put("message", ex.getMessage());
Integer statusCode = (Integer) request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);
return new ResponseEntity<>(result, HttpStatus.valueOf(statusCode));
}
produces = MediaType.APPLICATION_JSON_VALUE
- 클라이언트가 요청하는 HTTP Header의 Accept 의 값이 application/json 일 때 해당 메서드가 호출
- 결국 클라어인트가 받고 싶은 미디어타입이 json이면 이 컨트롤러의 메서드가 호출된다.
📗 API 예외 처리 - 스프링 부트 기본 오류 처리
BasicErrorController 코드
@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) {}
@RequestMapping
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {}
- errorHtml() : produces = MediaType.TEXT_HTML_VALUE : 클라이언트 요청의 Accept 해더 값이 text/html인 경우에는 errorHtml()을 호출해서 view를 제공
- error() : 그외 경우에 호출되고 ResponseEntity로 HTTP Body에 JSON 데이터를 반환
결과
{
"timestamp": "2021-04-28T00:00:00.000+00:00",
"status": 500,
"error": "Internal Server Error",
"exception": "java.lang.RuntimeException",
"trace": "java.lang.RuntimeException: 잘못된 사용자\n\tat
hello.exception.web.api.ApiExceptionController.getMember(ApiExceptionController
.java:19...",
"message": "잘못된 사용자",
"path": "/api/members/ex"
}
Html 페이지 vs API 오류
BasicErrorController를 확장하면 JSON 메시지도 변경할 수 있음.
그런데 API 오류는 조금 뒤에 설명할 @ExceptionHandler가 제공하는 기능을 사용하는 것이 더 나은 방법이므로
지금은 BasicErrorController를 확장해서 JSON 오류 메시지를 변경할 수 있다 정도로만 이해
스프링 부트가 제공하는 BasicErrorController는 HTML 페이지를 제공하는 경우에는 매우 편리.
그런데 API 오류 처리는 다른 차원의 이야기로 API 마다, 각각의 컨트롤러나 예외마다 서로 다른 응답 결과를 출력해야 할 수도 있음.
예를 들어서 회원과 관련된 API에서 예외가 발생할 때 응답과,
상품과 관련된 API에서 발생하는 예외에 따라 그 결과가 달라질 수 있음.
결과적으로 매우 세밀하고 복잡하므로 이 방법은 HTML 화면을 처리할 때 사용하고,
API는 오류 처리는 뒤에서 설명할 @ExceptionHandler를 사용
📕 HandlerExceptionResolver
목표
예외가 발생해서 서블릿을 넘어 WAS까지 예외가 전달되면 HTTP 상태코드가 500으로 처리된다.
발생하는 예외에 따라서 400, 404 등등 다른 상태코드로 처리하고 싶다.
오류 메시지, 형식등을 API마다 다르게 처리하고 싶다.
[ApiExceptionController] - 수정
@GetMapping("/api/members/{id}")
public MemberDto getMember(@PathVariable("id") String id) {
if (id.equals("ex")) {
throw new RuntimeException("잘못된 사용자");
}
if (id.equals("bad")) {
throw new IllegalArgumentException("잘못된 입력 값");
}
return new MemberDto(id, "hello " + id);
}
실행해보면 상태 코드가 500인 것을 확인 할 수 있음
{
"status": 500,
"error": "Internal Server Error",
"exception": "java.lang.IllegalArgumentException",
"path": "/api/members/bad"
}
HandlerExceptionResolver
스프링 MVC는 컨트롤러(핸들러) 밖으로 예외가 던져진 경우 예외를 해결하고, 동작을 새로 정의할 수 있는 방법을 제공함.
컨트롤러 밖으로 던져진 예외를 해결하고, 동작 방식을 변경하고 싶으면 HandlerExceptionResolver( ExceptionResolver ) 를 사용
ExceptionResolver 적용 전
ExceptionResolver 적용 후
ExceptionResolver 로 예외를 해결해도 postHandle()은 호출되지 않음
📗 HandlerExceptionResolver
public interface HandlerExceptionResolver {
ModelAndView resolveException(HttpServletRequest request,
HttpServletResponse response, Object handler, Exception ex);
}
- handler : 핸들러(컨트롤러) 정보
- Exception ex : 핸들러(컨트롤러)에서 발생한 발생한 예외
[MyHandlerExceptionResolver]
@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;
}
}
ExceptionResolver가 ModelAndView를 반환하는 이유는
마치 try, catch를 하듯이, Exception을 처리해서 정상 흐름 처럼 변경하는 것이 목적이다
이름 그대로 Exception을 Resolver(해결)하는 것이 목적
반환 값에 따른 동작 방식
- 빈 ModelAndView : new ModelAndView()처럼 빈 ModelAndView를 반환하면
뷰를 렌더링 하지 않고, 정상 흐름으로 서블릿이 리턴 - ModelAndView 지정 : ModelAndView에 View, Model 등의 정보를 지정해서 반환하면 뷰를 렌더링
- null : null을 반환하면, 다음 ExceptionResolver를 찾아서 실행.
만약 처리할 수 있는 ExceptionResolver가 없으면 예외 처리가 안되고, 기존에 발생한 예외를 서블릿 밖으로 던짐
ExceptionResolver 활용
- 예외 상태 코드 변환
- 예외를 response.sendError(xxx) 호출로 변경해서 서블릿에서 상태 코드에 따른 오류를 처리하도록 위임
- 이후 WAS는 서블릿 오류 페이지를 찾아서 내부 호출, 예를 들어서 스프링 부트가 기본으로 설정한 /error가 호출됨
- 뷰 템플릿 처리
- ModelAndView에 값을 채워서 예외에 따른 새로운 오류 화면 뷰 렌더링 해서 고객에게 제공
- API 응답 처리
- response.getWriter().println("hello"); 처럼 HTTP 응답 바디에 직접 데이터를 넣어주는 것도 가능. 여기에 JSON 으로 응답하면 API 응답 처리가 가능
[WebConfig] - 수정
/**
* 기본 설정을 유지하면서 추가
*/
@Override
public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
resolvers.add(new MyHandlerExceptionResolver());
}
configureHandlerExceptionResolvers(..)를 사용하면 스프링이 기본으로 등록하는 ExceptionResolver가 제거되므로 주의, extendHandlerExceptionResolvers를 사용
📗 HandlerExceptionResolver 활용
[UserException]
package hello.exception.exception;
public class UserException extends RuntimeException {
public UserException() {
super();
}
public UserException(String message) {
super(message);
}
public UserException(String message, Throwable cause) {
super(message, cause);
}
public UserException(Throwable cause) {
super(cause);
}
protected UserException(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace) {
super(message, cause, enableSuppression, writableStackTrace);
}
}
[ApiExceptionController] - 예외 추가
@Slf4j
@RestController
public class ApiExceptionController {
@GetMapping("/api/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 new MemberDto(id, "hello " + id);
}
@Data
@AllArgsConstructor
static class MemberDto {
private String memberId;
private String name;
}
}
[UserHandlerExceptionResolver]
@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;
}
}
[WebConfig] - UserHandlerExceptionResolver 추가
@Override
public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
resolvers.add(new MyHandlerExceptionResolver());
resolvers.add(new UserHandlerExceptionResolver());
}
정리
- ExceptionResolver 를 사용하면 컨트롤러에서 예외가 발생해도
ExceptionResolver 에서 예외를 처리해버린다. - 따라서 예외가 발생해도 서블릿 컨테이너까지 예외가 전달되지 않고,
스프링 MVC에서 예외 처리는 끝이 난다. - 결과적으로 WAS 입장에서는 정상 처리가 된 것이다.
이렇게 예외를 이곳에서 모두 처리할 수 있다는 것이 핵심이다. - 서블릿 컨테이너까지 예외가 올라가면 복잡하고 지저분하게 추가 프로세스가 실행된다.
반면에 ExceptionResolver 를 사용하면 예외처리가 상당히 깔끔해진다.
📕 스프링이 제공하는 ExceptionResolver
- ExceptionHandlerExceptionResolver
- @ExceptionHandler을 처리. API 예외 처리는 대부분 이 기능으로 해결
- ResponseStatusExceptionResolver
- HTTP 상태 코드를 지정
- 예) @ResponseStatus(value = HttpStatus.NOT_FOUND)
- DefaultHandlerExceptionResolver
- 스프링 내부 기본 예외 처리
- 우선 순위가 가장 낮음
📗 ResponseStatusExceptionResolver
ResponseStatusExceptionResolver는 예외에 따라서 HTTP 상태 코드를 지정 다음 두 가지 경우를 처리
- @ResponseStatus가 달려있는 예외
- ResponseStatusException 예외
다음과 같이 @ResponseStatus 애노테이션을 적용하면 HTTP 상태 코드를 변경
@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "잘못된 요청 오류")
public class BadRequestException extends RuntimeException {
}
BadRequestException 예외가 컨트롤러 밖으로 넘어가면
ResponseStatusExceptionResolver 예외가 해당 애노테이션을 확인해서
오류 코드를 HttpStatus.BAD_REQUEST (400)으로 변경하고, 메시지도 저장
ResponseStatusExceptionResolver 코드를 확인해보면
결국 response.sendError(statusCode, resolvedReason)를 호출,
sendError(400)를 호출했기 때문에 WAS에서 다시 오류 페이지( /error )를 내부 요청
[ApiExceptionController] - 추가
@GetMapping("/api/response-status-ex1")
public String responseStatusEx1() {
throw new BadRequestException();
}
결과
{
"status": 400,
"error": "Bad Request",
"exception": "hello.exception.exception.BadRequestException",
"message": "잘못된 요청 오류",
"path": "/api/response-status-ex1"
}
메시지 기능 reason을 MessageSource에서 찾는 기능도 제공. reason = "error.bad"
@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "error.bad")
public class BadRequestException extends RuntimeException {
}
[messages.properties]
error.bad=잘못된 요청 오류입니다. 메시지 사용
메시지 사용 결과
{
"status": 400,
"error": "Bad Request",
"exception": "hello.exception.exception.BadRequestException",
"message": "잘못된 요청 오류입니다. 메시지 사용",
"path": "/api/response-status-ex1"
}
ResponseStatusException
@ResponseStatus는 개발자가 직접 변경할 수 없는 예외에는 적용할 수 없음.
(애노테이션을 직접 넣어야 하는데, 내가 코드를 수정할 수 없는 라이브러리의 예외 코드 같은 곳에는 적용할 수 없음.)
추가로 애노테이션을 사용하기 때문에 조건에 따라 동적으로 변경하는 것도 어려움.
이때는 ResponseStatusException 예외를 사용
[ApiExceptionController] - 추가
@GetMapping("/api/response-status-ex2")
public String responseStatusEx2() {
throw new ResponseStatusException(HttpStatus.NOT_FOUND, "error.bad", new IllegalArgumentException());
}
결과
{
"status": 404,
"error": "Not Found",
"exception": "org.springframework.web.server.ResponseStatusException",
"message": "잘못된 요청 오류입니다. 메시지 사용",
"path": "/api/response-status-ex2"
}
📗 DefaultHandlerExceptionResolver
DefaultHandlerExceptionResolver는 스프링 내부에서 발생하는 스프링 예외를 해결
- 대표적으로 파라미터 바인딩 시점에 타입이 맞지 않으면 내부에서 TypeMismatchException이 발생하는데,
- 이 경우 예외가 발생했기 때문에 그냥 두면 서블릿 컨테이너까지 오류가 올라가고, 결과적으로 500 오류가 발생
- 그런데 파라미터 바인딩은 대부분 클라이언트가 HTTP 요청 정보를 잘못 호출해서 발생하는 문제
- HTTP 에서는 이런 경우 HTTP 상태 코드 400을 사용
- DefaultHandlerExceptionResolver는 이것을 500 오류가 아니라 HTTP 상태 코드 400 오류로 변경
[ApiExceptionController] - 추가
@GetMapping("/api/default-handler-ex")
public String defaultException(@RequestParam Integer data) {
return "ok";
}
Integer data에 문자를 입력하면 내부에서 TypeMismatchException이 발생
결과
{
"status": 400,
"error": "Bad Request",
"exception":
"org.springframework.web.method.annotation.MethodArgumentTypeMismatchException",
"message": "Failed to convert value of type 'java.lang.String' to required type 'java.lang.Integer'; nested exception is java.lang.NumberFormatException: For input string: \"hello\"",
"path": "/api/default-handler-ex"
}
📕 @ExceptionHandler
📗 HTML 화면 오류 vs API 오류
- 웹 브라우저에 HTML 화면을 제공할 때는 오류가 발생하면 BasicErrorController를 사용하여
단순히 5xx, 4xx 관련된 오류 화면을 보여주면 됨 - 그런데 API는 각 시스템 마다 응답의 모양도 다르고, 스펙도 모두 다름.
- 예외 상황에 단순히 오류 화면을 보여주는 것이 아니라, 예외에 따라서 각각 다른 데이터를 출력해야 할 수도 있음.
- 그리고 같은 예외라고 해도 어떤 컨트롤러에서 발생했는가에 따라서 다른 예외 응답을 내려주어야 할 수 있다.
- 한마디로 매우 세밀한 제어가 필요.
앞서 이야기했지만, 예를 들어서 상품 API와 주문 API는 오류가 발생했을 때 응답의 모양이 완전히 다를 수 있음.
결국 지금까지 살펴본 BasicErrorController를 사용하거나 HandlerExceptionResolver를 직접 구현하는 방식으로 API 예외를 다루기는 쉽지 않음.
📗 API 예외처리의 어려운 점
- HandlerExceptionResolver를 떠올려 보면 ModelAndView를 반환해야 하나 이것은 API 응답에는 필요하지 않음
- API 응답을 위해서 HttpServletResponse에 직접 응답 데이터를 넣어주는 것은 매우 불편.
- 스프링 컨트롤러에 비유하면 마치 과거 서블릿을 사용하던 시절로 돌아간 것 같음
- 특정 컨트롤러에서만 발생하는 예외를 별도로 처리하기 어려움.
- 예를 들어서 회원을 처리하는 컨트롤러에서 발생하는 RuntimeException 예외와 상품을 관리하는 컨트롤러에서 발생하는 동일한 RuntimeException 예외를 서로 다른 방식으로 처리하고 싶다면?
📗 @ExceptionHandler
- 스프링은 API 예외 처리 문제를 해결하기 위해
@ExceptionHandler라는 애노테이션을 사용하는 매우 편리한 예외 처리 기능을 제공 - 이것이 바로 ExceptionHandlerExceptionResolver.
- 스프링은 ExceptionHandlerExceptionResolver를 기본으로 제공하고,
기본으로 제공하는 ExceptionResolver 중에 우선순위도 가장 높음. - 실무에서 API 예외 처리는 대부분 이 기능을 사용.
[ErrorResult] - 예외가 발생했을 때 API 응답으로 사용하는 객체
@Data
@AllArgsConstructor
public class ErrorResult {
private String code;
private String message;
}
[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 new MemberDto(id, "hello " + id);
}
@Data
@AllArgsConstructor
static class MemberDto {
private String memberId;
private String name;
}
}
@ExceptionHandler 예외 처리 방법
- @ExceptionHandler 애노테이션을 선언하고, 해당 컨트롤러에서 처리하고 싶은 예외를 지정.
- 해당 컨트롤러에서 예외가 발생하면 이 메서드가 호출됨.
- 참고로 지정한 예외 또는 그 예외의 자식 클래스는 모두 잡을 수 있음
다음 예제는 IllegalArgumentException 또는 그 하위 자식 클래스를 모두 처리 가능
@ExceptionHandler(IllegalArgumentException.class)
public ErrorResult illegalExHandle(IllegalArgumentException e) {
log.error("[exceptionHandle] ex", e);
return new ErrorResult("BAD", e.getMessage());
}
우선순위
- 스프링의 우선순위는 항상 자세한 것이 우선권을 가짐.
- 예를 들어서 부모, 자식 클래스가 있고 다음과 같이 예외가 처리됨
@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) {}
파라미터와 응답
@ExceptionHandler에는 마치 스프링의 컨트롤러의 파라미터 응답처럼 다양한 파라미터와 응답을 지정할 수 있음
📗 IllegalArgumentException 처리
@ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(IllegalArgumentException.class)
public ErrorResult illegalExHandle(IllegalArgumentException e) {
log.error("[exceptionHandle] ex", e);
return new ErrorResult("BAD", e.getMessage());
}
실행 흐름
- 컨트롤러를 호출한 결과 IllegalArgumentException 예외가 컨트롤러 밖으로 던져짐
- 예외가 발생했으로 ExceptionResolver가 작동.
- 가장 우선순위가 높은 ExceptionHandlerExceptionResolver가 실행
- ExceptionHandlerExceptionResolver는 해당 컨트롤러에 IllegalArgumentException을 처리할 수 있는 @ExceptionHandler가 있는지 확인
- illegalExHandle()를 실행.
- @RestController이므로 illegalExHandle()에도 @ResponseBody가 적용됨.
- 따라서 HTTP 컨버터가 사용되고, 응답이 다음과 같은 JSON으로 반환됨.
- @ResponseStatus(HttpStatus.BAD_REQUEST)를 지정했으므로 HTTP 상태 코드 400으로 응답
결과
{
"code": "BAD",
"message": "잘못된 입력 값"
}
📗 UserException 처리
@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);
}
- @ExceptionHandler에 예외를 지정하지 않으면 해당 메서드 파라미터 예외를 사용.
- 여기서는 UserException을 사용
- ResponseEntity를 사용해서 HTTP 메시지 바디에 직접 응답. 물론 HTTP 컨버터가 사용됨.
- ResponseEntity를 사용하면 HTTP 응답 코드를 프로그래밍해서 동적으로 변경 가능.
- 앞서 살펴본 @ResponseStatus는 애노테이션이므로 HTTP 응답 코드를 동적으로 변경할 수 없음
📗 Exception 처리
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
@ExceptionHandler
public ErrorResult exHandle(Exception e) {
log.error("[exceptionHandle] ex", e);
return new ErrorResult("EX", "내부 오류");
}
- throw new RuntimeException("잘못된 사용자") 이 코드가 실행되면서, 컨트롤러 밖으로 RuntimeException이 던져짐
- RuntimeException은 Exception의 자식 클래스이므로 이 메서드가 호출됨
- @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)로 HTTP 상태 코드를 500으로 응답
📗 기타 처리
다음과 같이 ModelAndView를 사용해서 오류 화면(HTML)을 응답하는데 사용할 수도 있음
@ExceptionHandler(ViewException.class)
public ModelAndView ex(ViewException e) {
log.info("exception e", e);
return new ModelAndView("error");
}
📕 @ControllerAdvice
@ExceptionHandler를 사용해서 예외를 깔끔하게 처리할 수 있게 되었지만,
정상 코드와 예외 처리 코드가 하나의 컨트롤러에 섞여 있음.
@ControllerAdvice 또는 @RestControllerAdvice를 사용하면 둘을 분리 가능
[ExControllerAdvice]
@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", "내부 오류");
}
}
[ApiExceptionV2Controller] - @ExceptionHandler 모두 제거
@Slf4j
@RestController
public class ApiExceptionV2Controller {
@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 new MemberDto(id, "hello " + id);
}
@Data
@AllArgsConstructor
static class MemberDto {
private String memberId;
private String name;
}
}
📗 @ControllerAdvice
- @ControllerAdvice는 대상으로 지정한 여러 컨트롤러에 @ExceptionHandler, @InitBinder 기능을 부여해주는 역할
- @ControllerAdvice에 대상을 지정하지 않으면 모든 컨트롤러에 적용 (글로벌 적용)
- @RestControllerAdvice는 @ControllerAdvice와 같고, @ResponseBody가 추가되어 있음.
- @Controller, @RestController의 차이와 같음
대상 컨트롤러 지정 방법
// 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 {}