Spring MVC 2 - API 예외 처리 HandlerExceptionResolver
1. API 예외 처리 - 시작
- API 예외 처리는 어떻게 해야할 까?
- HTML 페이지를 보여주어야 하는 경우 쉽게 처리할 수 있었다.
- API 예외는 각 오류 상황에 맞는 오류 응답 스펙을 정의하고, JSON으로 데이터를 내려주어야 한다.
@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;
}
- 테스트용 컨트롤러이다.
- 정상 호출 시 HTTP 메시지 컨버터에 의해 MemberDto가 Json으로 변경되어 잘 출력됨
- 에러 발생 시 무슨 html이 날아감 -> (/error-page/500 호출의 결과)
1.1 ErrorPageController 수정
@RequestMapping(value = "/error-page/500", produces = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<Map<String, Object>> errorPage500Api (HttpServletRequest
request, HttpServletResponse response){
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));
}
- 응답 데이터를 위해 Map을 만들고 status,message키에 값을 할당함 Jackson 라이브러리는 Map To Json 지원함
- ResponseEntity를 사용하기 때문에 메시지 컨버터가 동작한다.
* HttpStatus.valueOf(Integer)로 상태코드 만들 수 있다.!
* Accept - produces, Content-Type - consumes
* 수동으로 등록한 ErrorPage에 의해 동작 중임!
2. API 예외 처리 - 스프링 부트 기본 오류 처리
- API 예외 처리도 스프링 부트가 제공하는 기본 오류 방식을 사용할 수 있다.
- 다음 BasicErrorController의 코드를 보자
@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse
response) {}
@RequestMapping
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {}
- BasicErrorController를 보면 같은 URL에 MediaType에 따라 view 혹은 ResponseEntity를 제공함을 볼 수 있다.
- BasicErrorController가 원래 에러 페이지에 쓸 수 있도록 request에 기본으로 담아주는 값들을 JSON으로 만들어서 출력한다.
* 스프링 부트는 기본으로 오류 발생시 /error 내부 호출 (server.error.path로 수정 가능)
2.1 HTML 페이지 VS API 오류
- 스프링 부트가 기본으로 제공하는 BasicErrorController는 HTML 페이지 제공시 매우 편리함
- 다만 API는 각각의 컨트롤러나 예외 마다 다른 응답 결과를 출력해야 할 수도 있다.
- 따라서 API 오류 처리는 @ExceptionHandler를 사용하도록 하자
3. API 예외 처리 - HandlerExceptionResolver 시작
- 일단 컨트롤러 Exception (상태코드 500)을 예외에 따라 400,404 등으로 고쳐보자
- ex IllegalArgumentException을 400으로 처리해보자
@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);
}
3.1 HandlerExceptionResolver 이란
- 컨트롤러 밖으로 예외가 던져지면, 예외를 해결하고, 동작을 새로 정의할 수 있게 해준다.
- 예외가 발생하면, 마치 인터셉터처럼 ExceptionResolver가 작동하고, 예외를 처리 + 동작 변경 등등 할 수 있다.
* ExceptionResolver로 예외를 처리해도 postHandle()은 호출되지 않음
public interface HandlerExceptionResolver {
ModelAndView resolveException(
HttpServletRequest request, HttpServletResponse response,
Object handler, Exception ex);
}
- 예외를 중간에서 받아 처리하고, 핸들러 어댑터 대신에 DispatcherServlet으로 정상 처리 된 것 처럼 ModelAndView를 반환해준다.
public class MyHandlerExceptionResolver implements HandlerExceptionResolver {
@Override
public ModelAndView resolveException(HttpServletRequest request,
HttpServletResponse response, Object handler, Exception ex) {
try{
if(ex instanceof IllegalArgumentException){
response.sendError((HttpServletResponse.SC_BAD_REQUEST, ex.getMessage());
return new ModelAndView();
}
} catch (IOException e) {
log.error("resolver ex", e);
}
return null;
}
}
- 지금은 예외 처리한게 아니라 예외를 바꿔서 다시 던진 것
- 따라서 굳이 ModelAndView에 뭘 넣어서 리턴할 필요 없었다.
- ModelAndView를 반환하는 이유는 원래 try,catch해서 Exception을 처리한 뒤 정상 흐름으로 변경하는 것이 목적
- ExceptionResolver를 사용하면 공통 에러를 쉽게 처리할 수 있다.
* 반환 값에 따른 동작 방식 (DispatcherServlet)
-> 빈 ModelAndView : 뷰 랜더링 x 정상 흐름 서블릿 리턴
-> ModelAndView지정 : 뷰 랜더링 함
-> null : ExceptionResolver를 찾아서 실행함 -> 만약 처리할 수 없다면 서블릿 밖으로 예외 던짐
3.2 WebConfig에 등록
public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers){
resolvers.add(new MyHandlerExceptionResolver());
}
* 꼭 extend~를 사용하자 configure~를 사용하면 기본 ExceptionResolver가 제거됨
3.3 ExceptionResolver의 역할
1. 예외 상태 코드 변환 : response.sendError() -> 이후 WAS가 오류 페이지 내부 호출 (/error)
2. 뷰 템플릿 처리 : ModelAndView에 값을 채워서 예외에 따른 새로운 화면 랜더링 가능
3. API 응답 처리 : response.getWriter()을 활용해서 HTTP 응답 바디에 직접 데이터 넣을 수 있다.
(JSON으로 응답하면 API 응답 처리 가능)
4. HandlerExceptionResolver 활용
- 예외 마무리 하기 가능하다
- 기존 예외 발생시 WAS까지 던졌다가 다시 오류 페이지 찾고 이런 과정 너무 복잡
- 예외 발생 했을 때 복잡한 과정 없이 깔끔하게 처리해보자
public class UserHandlerExceptionResolver implements HandlerExceptionResolver {
private final ObjectMapper obm = new ObjectMapper();
@Override
public ModelAndView resolveException(HttpServletRequest request,
HttpServletResponse response, Object handler, Exception ex){
try{
if(ex instanceof UserException){
//클라이언트 accept 꺼내기
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 = obm.writeValueAsString(errorResult); //JSON String으로 변환
response.setContentType("application/json");
response.setCharacterEncoding("utf-8");
response.getWriter().write(result);
return new ModelAndView();
}else{
return new ModelAndView("error/500");
}
}
//..
}
- HTTP 요청 헤더의 ACCEPT값을 확인해서 JSON 혹은 HTML 오류 페이지 보여준다.
- 컨트롤러 예외 발생시 ExceptionResolver가 먼저 받는다.
- 서블릿 컨테이너까지 예외 전달하지 않고, 스프링 MVC에서 예외 처리 가능하다.
- 결론적으로 WAS 입장에서는 정상처리 완료이다.
- 많은 예외를 컨트롤러 단위가 아니라 더 큰 단위로 처리할 수 있다.
- 장점이 있으나, 구현이 어렵다 스프링에서 제공하는 ExceptionResolver를 알아보자
*결론적으로 위와 같이 활용하면 좋을 것 같다.