스프링 mvc2 - 7. API 예외 처리

1. API 통신

• Api 통신
  • 일반적인 웹사이트 통신
    • client와 개발자가 만든 server와 http protocal을 기반으로 통신을 한다.
    • 그래서 보통은 html의 form 혹은 queary를 통해서 요청 data를 주면 server에서는 java, node.js , phython 등 사용한 백엔드 언어를 통해서 data 혹은 html view를 response를 해준다.
      
      
  • api 통신
    • server와 server 간의 통신이 대표적
      ex) client가 웹사이트에서 날씨 정보를 클릭하면 server는 서로 호환하고 있는 날씨 서버의 api와 통신 후 받은 data를 client에게 줄 때도 api 통신이 이용된다.
    • api 통신은 보통 주 목적이 data를 주고 받는 것이기에 html이 아닌 JSON 형태로 서로 data를 주고 받는다.
      
      
  • api 추가 설명
    • Interface와 API

 

2. API 예외 처리 - servlet 방식

• 이전까지의 예외 처리는 html에서 사용자 에러나 서버의 에러에 관한 내용이기에
  templetes/error 경로에 error 관련 html 파일만 만들면 된다.
  
  
• api 같은 경우에는 보통 json을 통해서 data를 주고 받기에 이 부분에서 error가 생기면 JSON 형태의 error JSON 를 보여줘야한다.
  
  
• 하지만 server 입장에서는 그저 exception일 뿐이므로 가지고 있는 errorPage인 html 파일로 에러를 나타낸다.
  
  
• 그래서 json인 경우 error 처리하는 방법을 구현해야한다.
  produce = MediaType 이용

 

• json data를 받을 controller 생성

package hello.exception.api;

@Slf4j
@RestController // api 중 json 형식으로 받을 때 사용
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;
    }
}

 

• 직접 만든 ErrorController - api 응답 추가 <basicErrorController의 내부 구현 logic 정도로 이해하기>

package hello.exception.servlet;

@Slf4j
@Controller
public class ErrorPageController {

    //RequestDispatcher 상수로 정의되어 있음 - 다시 에러페이지 호출을 위한 controller 들어갈 시 필요 정보들을 뽑아낼 수 있다.
    public static final String ERROR_EXCEPTION = "jakarta.servlet.error.exception";
    public static final String ERROR_EXCEPTION_TYPE = "jakarta.servlet.error.exception_type";
    public static final String ERROR_MESSAGE = "jakarta.servlet.error.message";
    public static final String ERROR_REQUEST_URI = "jakarta.servlet.error.request_uri";
    public static final String ERROR_SERVLET_NAME = "jakarta.servlet.error.servlet_name";
    public static final String ERROR_STATUS_CODE = "jakarta.servlet.error.status_code";

    // 웹 통신 error
    @RequestMapping("/error-page/500")
    public String errorPage500(HttpServletRequest request, HttpServletResponse response) {
        log.info("errorPage 500");
        printErrorInfo(request); // 오류 정보 넣어주기
        return  "error-page/500";
    }
    
    // API 통신 error
    @RequestMapping(value = "/error-page/500", produces = MediaType.APPLICATION_JSON_VALUE)
    // 바로 위에 동일한 mapping url이 존재하지만 mediaType(Spring꺼)이 json일 때 우선권을 가진다.
    public ResponseEntity<Map<String, Object>> errorPage500Api(HttpServletRequest request, HttpServletResponse response) {
        log.info("API errorPage 500");

        Exception ex = (Exception) request.getAttribute(ERROR_EXCEPTION);

        Map<String, Object> result = new HashMap<>();
        result.put("status", request.getAttribute(ERROR_STATUS_CODE));
        result.put("message", ex.getMessage());

//        Integer statusCode = (Integer) request.getAttribute(ERROR_STATUS_CODE); // 결과 동일
        Integer statusCode = (Integer) request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);

        return new ResponseEntity<>(result, HttpStatus.valueOf(statusCode));
    }

   ... 생략
}

 

3.API 예외 처리 - spring boot 기본 오류 처리 방식

• 복기
  • 예외 발생 -> WAS 까지 예외 전달 -> WAS가 springboot에서 등록한 ErrorCustom 찾은 후 다시 /error URL 호출
    -> /error Mapping을 가진 것이 BasicErrorController 이다.

 

• BasicErrorController 
  • "accept" 요청 종류에 따라서 이미 개발이 완료되어있다.
    
    
  • errorHtml() : client 요청의 accept 해더 값이 text/html인 경우 view 제공
  • error(): 그 외 경우 ResponseEntity로 Http body에 JSON data 반환
    
    • 요청이 json일 경우 예외 발생시 알아서 json 형태의 message를 보내준다.
    • was 요청을 2번 돈다.
  • 옵션을 설정해서 더 자세한 오류 정보 추가 가능 ex) always, never, true 했던 것
    하지만 실제 노출되는 화면에는 최대한 안보이도록 하고 로그를 통해서 확인 하도록 하자

//  /error 로 들어온 것들 중에서 text/html 타입이면 처음께 적용 되고 - ModelAndView 반환
@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) {}

//  나머지 타입들은 ResponseEntity 형식은 Http messageBody에 data를 json으로 직접 넣는 방식으로 반환
@RequestMapping
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {}

 

3.1. HTML 페이지 vs API 오류

• BasicErrorController 확장 하면 JSON 메시지도 변경 가능
  
  
• @ExceptionHandler 사용하는 것이 BasicErrorController 사용보다 나은 방법이므로 방법이 존재한다 정도로만 이해
  
  
• HTML 페이지 제공하는 경우 BasicErrorController 가 편리
  
  
• 하지만 API 경우 차원이 다르다. -> 각각의 controller나 예외마다 서로 다른 응답 결과를 출력해야하기 때문
  • 회원 관련 API , 상품관련 API 발생하는 예외에 따라 결과가 다르다.
    * 해당 data는 DB로 부터 받아오니깐 API 통신이 맞다
    
    
  • 그래서 BasicErrorController 방식이 맞지 않다.
  • 참고
    • handlerExceptionResolver에서 2가지 기능을 수행하는데 1) errorStatus 변환 2) BasicErrorController 사용 안하는 방법을 보여준다.
      1.  4.3. : errorStatus 변환
      2.  4.4. : basicErrorController 사용 안하는 방법
• 결론
  • BasicErrorController : HTML 화면 처리할 때 사용
  • @ExceptionHandler : API 오류 처리에 사용

 

4. API 예외 처리 - HandlerExceptionResolver 시작

 

• 목표 : 예외가 발생하면 여태까지 500 에러로 처리되었다. 하지만 예외에 따라서 500이 아닌 400으로 나타나야하는 경우가 있다.
  
  
• 예
  • IllegallArgumentException을 처리하지 못해서 컨트롤러 밖으로 넘어가는 경우  == 사용자가 Argument를 잘못보낸 경우
    
    
  • 사용자의 잘못이지만 WAS 입장에서는 controller에서 해결하지 못한 예외가 날라온 경우이기 때문에 controller에서 처리를 못했다는 것이 주가 되어서 500을 날리게 된다. 항상 그렇다.
• 해결방안
  • HandlerExceptinResolver (예외 해결자) 라는 것을 통해서 예외를 해결하고 동작을 새로 정의할 수 있는 방법을 제공

 

4.1. HandlerExceptionResolver 작동 방식

• 보통 ExceptionResolver라고 간략화 해서 부른다.
• 예외가 발생 했을 때 DispatcherServlet에서 WAS로 가기전에 ExceptionResolver로 무조건 들른다. 예외 요청의 Accept와 관계 없이 무조건 거친다.
  
  

 

4.2. HandlerExceptionResolver sourceCode

 

public interface HandlerExceptionResolver {
   @Nullable
   ModelAndView resolveException(
         HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex);
         // handler : 컨트롤러 정보
         // Exception ex : 컨트롤러에서 발생한 예외
}

 

• ExceptionResovler의 반환 타입이 ModelAndView 인 이유
  • try-catch하듯이, Exception을 처리해서 정상 흐름 처럼 변경하는 것이 목적
    
    
• 반환값에 따른 동작 방식
  1. 비어있는 ModelAndView
     • new ModelAndView() 처럼 빈 ModelAndView를 반환하면 뷰를 렌더링 하지 않고 정상 흐름으로 서블릿이 return 된다.
     • 반환하기 전에 sendError()를 통해서 500으로 날라가야되는 예외를 sendError()로 바꿔치기해서 정상 흐름 작동 후 WAS에서 sendError()를 확인 후 재 요청을 날리도록한다. -> 이 과정에서 500에서 다른 status로 변경을 할 수 있는 기회가 생긴다.
       * 주의: 현 예제의 경우 sendError 사용한 것이지 항상 쓰는 것은 아니다.
  2. ModelAndView 지정
     • 비어있는 ModelAndView가 아니라 실제 view와 연결을 시켜줘서 view를 렌더링해서 보내준다.
  3. null
     • 다음 HandlerExceptionResolver를 찾아서 실행 - 여러개 등록이 가능하기 때문
     • 처리가능한 HandlerExceptionResolver이 없을 시 예외를 그대로 날린다.
       
       
       
• ExceptionResolver 활용 - 앞으로 설명 할 것들
  1. 예외 상태 코드 변환 - 현재 한 것
  2. 뷰 템플릿 처리 - 5. API 예외처리에서 할 것들
  3. API 응답 처리 - 5. API 예외처리에서 할 것들

 

4.3. HandlerExceptionResolver 사용법 - 직접 만든 exceptionResolver

 

• 사용자 오류 json 코드

@Slf4j
@RestController // api 중 json 형식으로 받을 때 사용
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("잘못된 입력 값");

        return new MemberDto(id, "hello " + id);
    }
}

 

• MyHandlerExceptionResolver

package hello.exception.resolver;

@Slf4j
public class MyHandlerExceptionResolver implements HandlerExceptionResolver {

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {

        // ex: 이전 api controller에서 발생한 exception
        try {
            
            log.info("Accept가 text/html이든 application/json이든 일단 예외가 터질때 다 받음 ", ex);

            if (ex instanceof IllegalArgumentException) {
                log.info("IllegalArgumentException resolver to 400");
                response.sendError(HttpServletResponse.SC_BAD_REQUEST, ex.getMessage()); // 이전 예외를 먹어버리고 sendError를 통해서 내가 원하는 status로 예외 바꿔치기
                return new ModelAndView(); // 정상적으로 was까지 넘기고 -> WAS에서 sendError 확인함 // console 창 에는 error 관련된 뭔가가 뜨지 않는다.
            }
        } catch (IOException e) {
            log.error("resolver ex", e);
        }
        return null; //Illegalexception도 아니고 IOException도 아닐 때 ex가 터진 상태 그대로 WAS까지 날림
    }
}

• 동작 방식
  1. sendError()로 400 error로 변경 후 정상 흐름으로 was로 올라간다.
  2. was는 400 sendError를 본 후 springBoot의 basicErrorController에서 알아서 json을 예외를 다시 뿌려준다.

 

 

• webConfig에 등록하기
  • 2가지 방식의 overriding을 통해서 등록 가능
    1. extendHandlerExceptionresolvers(): 권장
    2. configureHandlerexceptionResolvers() : 권장 안함
       -> 이걸로 등록하게 되면 spring이 제공하는 HandlerExceptionresolver 를 제거 시키기 때문에 나중에 불편해짐

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
        resolvers.add(new MyHandlerExceptionResolver());
    }

//    나중에 사용할 스프링이 기본으로 제공하는 ExceptionResolver 가 제거되므로 사용 안하는 것을 추천
//    현재는 직접 만든 MyHandlerExceptionResolver 사용하므로 상관 없음
//    @Override
//    public void configureHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
//        resolvers.add(new MyHandlerExceptionResolver());
//    }

... 생략
}

 

5. API 예외 처리 - HandlerExceptionResolver 활용

• 활용 목적
  • 예외 발생시 WAS 예외 던지고 WAS 가 다시 요청 보내고 하는 모든 과정이 복잡하다. 
  • HandlerExceptionResolver를 통해서 예외 발생시 정상 처리로 변환 후 WAS로 도착후 종료되도록 할 수 있다.
  • HandlerExceptionResolver 내부에서 뷰 템플릿 처리, API 처리를 다 수행한다.

 

• 사용자 정의 예외 만들기

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);
    }
}

 

• controller

@Slf4j
@RestController // api 중 json 형식으로 받을 때 사용
public class ApiExceptionController {
    @GetMapping("/api/members/{id}")
    public MemberDto getMember(@PathVariable("id") String id) {

        if (id.equals("user-ex")) {
            throw new UserException("사용자 오류");
        }

        return new MemberDto(id, "hello " + id);
    }

 

• UserHandlerExceptionResolver

package hello.exception.resolver;

@Slf4j
public class UserHandlerExceptionResolver implements HandlerExceptionResolver {

    private final ObjectMapper objectMapper = new ObjectMapper(); //Json 형태를 string 형태의 map으로 받기 위한 것

    @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"); // 해당 string을 이용해서 application/json 과 나머지 상황을 분류 할 것이다.
                response.setStatus(HttpServletResponse.SC_BAD_REQUEST); // 어떤 Accept 인지 관계 없이 해당 예외인 경우는 status를 400으로 지정하기 위한 코드

                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 {
                    // json이 아닌 accept 인 경우
                    return new ModelAndView("error/404"); // 실제 작성한 view로 넘겨버림
                }
            }
        } catch (IOException e) {
            log.error("resolver ex", e);
        }
        return null;
    }
}

• 작동 방식
  • if 문 - 해당 에러인 경우
    1. 먼저 로그 찍고 accept 가 뭔지 string 출력
    2. 그리고 response.setStatus를 404로 설정
       
       
       1. 내부 if문 - string으로 만든 accept가 application/json인경우 작동하도록
          
          1. response에 담아서 보낼 json 형태 error 데이터 보냄
          2. return new ModelAndView(); 통해서 view 안찾고 바로 WAS로 감
       2. else - application/json 아닌 모든 경우
          1. return new ModelAndView("error/404"); :  실제 작성한 view 위치를 찍어서 보내줌 - 정상작동이 error page를 보여주면서 종료됨
  • 제일 처음 if문에 안들어간 경우
    
    • return null; :  예외가 해당 조건에 없는 경우, 다른 HandlerExceptionResolver 찾으러 가거나 없으면 예외를 WAS에 반환

 

 

6. API 예외 처리 - 스프링이 제공하는 ExceptionResolver

 

• 스프링 부트가 기본으로 제공하는 ExceptionResolver
  
  
• HandlerExceptionResolverComposite에 우선순위별로 등록
  
  우선순위별로 찾는데 우선순위가 높은 것을 찾으면 밑에 것들은 진행이 안됨
  자동으로 구현되고 등록된거라서 눈에 안보임
  
  1. ExceptionHandlerExceptionResolver - 너무 중요, 따로 설명
  2. ResponseStatusExceptionResolver - Http 상태코드 지정
  3. DefaultHandlerExceptionResolver - 스프링 내부 기본 예외 처리

 

 

6.1. ResponseStatusExceptionResolver

 

• HTTP 상태 코드를 지정해준다.
  • @ResponseStatus(value = HttpStatus.NOT_FOUND)

 

• 2가지 경우 처리
  1. @ResponseStatus(code= , reason= ) 가 달려있는 예외
  2. ResponseStatusException 예외

 

6.1.1. @ResponseStatus 예시

• code: 상태코드 변경
• reason: 메시지 코드 작성 - 만약 messages.properties에 존재하지 않으면 reason의 String 자체가 출력

// 직접 만든 @ResponseStatus 예외
package hello.exception.exception;

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

// API controller

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

# resources/messages.properties

error.bad=잘못된 요청입니다. 메시지 사용

 

6.1.2. ResponseStatusExcetion

• @ResponseStatus 같이 개발자가 직접 변경할 수 없는 예외에는 적용할 수 없다. 이때는 ResponseStatusException 예외를 사용한다.
• 예외 던질 때 실제 발생한 예외를 ResponseStatusExcetion 내부에 넣어서 예외를 던진다.

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

 

6.2. DefaultHandlerExceptionResolver

• DefaultHandlerExceptionResolver: Spring 내부에서 발생하는 spring 예외를 해결
• 특히, params binding 예외는 대부분 client가 Http 요청정보를 잘못 호출해서 발생하는 문제
  
  
• ex)
  가격을 넣는 칸에 string을 넣으면 내부에서 TypeMismatchException이 발생 -> 잡지 않으면 WAS까지 올라가서 500 error가 발생하게 된다.
  하지만 위의 경우에는 client가 잘못 호출한 경우로 400 오류가 발생해야한다.
  
  
• spring 내부 오류 발생 시 DefaultHandlerExceptionResolver 내부에 정의 된 오류처리 방식에 따라서 400으로 해결된다.

@Slf4j
@RestController // api 중 json 형식으로 받을 때 사용
public class ApiExceptionController {
... 생략
    @GetMapping("/api/default-handler-ex")
    public String defaultException(@RequestParam Integer data) { 
    // 해당 params에 int가 들어와야한다. 아니면 TypeMismatchException 발생 
    // -> 원래는 500 하지만 sprint -> 400으로 바꿔줌
        return "ok";
    }
...생략
}

 

• postman으로 이상한 params를 넣을 때 400 error가 응답으로 나온다.

 

6.3. ExceptionHandlerExceptionResolver (매우 중요)

• 문제점들
  • api는 각 시스템 마다 응답의 모양과 스펙이 다르다. 예외에 따라서 각각 다른 데이터를 출력해야 할 수도 있다.
    
    • 각각 costum 해야하기 때문에 html 예외 발생시에는 basicErrorController를 권장하고
      api 같이 상황마다 달라져야하는 예외는 @ExceptionHandler를 권장한다.
  • 어떤 컨트롤러에서 발생했는가에 따라서 다른 예외 응답을 내려야하는 경우도 있다.
    걍 상황마다 다르게 처리를 해줘야 한다.
    
    
  • 이전에 한 handlerExceptionResolver는 ModelAndView를 반환 해서 원시시대처럼 API 응답을 넣기 위해서 일일이 다 넣어줘야했다.
    
    
• 문제점 정리
  1. HttpServletResponse에 직접 응답 데이터 넣기
  2. 특정 컨트롤러에서만 발생하는 예외를 별도로 처리
     
     
• 해결책
  • ExceptionHandlerExceptionResolver를 사용할 수 있게 하는 @ExceptionHandler 어노테이션 사용

 

• Json으로 보낼 데이터 넣을 class

package hello.exception.exhandler;

import lombok.AllArgsConstructor;
import lombok.Data;

@Data
@AllArgsConstructor
public class ErrorResult {
    // 오류 발생시 아래의 구조로 데이터를 보내도록 함
    private String code;
    private String message;
}

 

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

 

작동원리

1. /api2/members/bad -> IllegalArgumentException 발생
2. ExceptionResolver로 가서 예외 해결을 시도한다.
3. 우선순위 1순위인 ExceptionHandlerExceptionResolver는 controller에 @ExceptionHandler 존재 여부를 찾는다.
4. 해당 controller에 @ExceptionHandler가 존재하고 이 어노테이션은 IllegalArgumentException의 예외를 잡는다.
5. 조건이 부합해서 new ErrorResult() 객체를 반환하는데 @ExceptionHandler는 현 controller에 @RestController의 존재를 확인하고 해당 객체를 JSON 형식으로 변환해서 반환한다.
6. ExceptionResolver 과정을 통해서 정상흐름으로 동작이 변경되기때문에 상태코드가 200으로 나타난다.
7. 이를 원하는게 아니므로 @ResponseStatus()에 원하는 상태코드를 집어넣어서 원하는 상태코드를 반환한다.

 

6.3.1. 사용 예 1

package hello.exception.api;

@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());
    }
    
    @GetMapping("/api2/members/{id}")
    public MemberDto getMember(@PathVariable("id") String id) {
        
        if (id.equals("ex")) throw new RuntimeException("잘못된 사용자");
        if (id.equals("user-ex")) throw new UserException("사용자 오류");
        if (id.equals("bad")) throw new IllegalArgumentException("잘못된 입력 값");

        return new MemberDto(id, "hello " + id);
    }
    
    @Data
    @AllArgsConstructor
    static class MemberDto {
        private String memberId;
        private String name;
    }
}

 

6.3.2. 사용 예 2

• @ExceptionHandler(예외 class 생략 가능)

@ExceptionHandler // public의 params와 동일한 예외인 경우 생략 가능
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); // status setting을 ResponseEntity 내부에서 설정
}

 

6.3.3. 사용 예 3

• 미처 처리못한 예외 잡기

@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
@ExceptionHandler
public ErrorResult exHandle(Exception e) { // 위에서부터 params에 들어가는 예외는 해당 예외부터 자손 예외까지 포함한다.
    log.error("[exceptionHandle ex]", e);
    return new ErrorResult("EX", "내부 오류");
}

 

 

6.4. @ExceptionHandler 예외 처리 방법 정리

 

@ExceptionHandler 예외 처리 방법 정리 - 제일 중요

• @ExceptionHandler 어노테이션 선언하고, 해당 컨트롤러에서 처리하고 싶은 예외를 지정
• 다른 컨트롤러에선 적용 안된다.
• 지정한 예외 또는 그 예외의 자식 클래스 모두 잡을 수 있다.
  
  
• 우선 순위
  • 항상 자세한 것이 우선권을 가진다.
• 다양한 예외
  
  • 다양한 예외를 한번에 처리할 수 있다. @ExceptionHandler({AException.class, BExcetion.class})
• 예외 생략
  • 생략가능. 생략시 메서드 params의 예외가 지정된다. - 6.3.2. 사용 예시
• 파라미터와 응답
  • @ExceptionHandler에는 spring의 controller의 params 응답처럼 다양한 파라미터와 응답을 지정할 수 있다.
• 기타
  • ModelAndView를 사용해서 HTML 오류 화면을 응답하는데 사용할 수도 있다.
  • 사용할 수 있는거지 BasicErrorController를 사용을 권장한다.

 

 

6.5. API 예외 처리 - @ControllerAdvice

 

• @ExceptionHandler를 사용해서 예외를 깔끔하게 처리할 수 있게 됬지만, 정상 코드와 예외 처리코드가 하나의 컨트롤러에 섞여 있는 것을 @ControllerAdvice나 @RestControllerAdvice를 사용해서 코드의 분리를 시킬 수 있다.
  
  Rest붙은 것은 내부에 @ResponseBody만 들어가있을뿐 동일하다.
  
  
  
• 역할
  • 대상으로 지정한 여러 컨트롤러에 @ExceptionHandler, @InitBinder 기능을 부여해주는 역할을 한다.
  • @ControllerAdvice에 대상을 지정하지 않으면 모든 controller에 적용된다. 글로벌 적용
    
    
• 대상 컨트롤러 지정방법
  1. 특정 어노테이션이 있는 컨트롤러를 지정
  2. 특정 패키지를 직접 지정하기(하위 컨트롤러가 대상으로 지정된다.) - 실무에서 자주 사용
  3. 특정 클래스를 지정할 수 있다.

 

• errorControllerAdvice

package hello.exception.exhandler.advice;

@Slf4j
@RestControllerAdvice(basePackages = "hello.exception.api") // @controllerAdvice + @ResponseBody
public class ExControllerAdvice {
    @ResponseStatus(HttpStatus.BAD_REQUEST) // 원래는 return 되는 new ErrorResult는 정상흐름의 결과로 200이 나와야하는 것을 400으로 설정해줌
    @ExceptionHandler(IllegalArgumentException.class)
    public ErrorResult illegalExHandle(IllegalArgumentException e) {
        log.error("[exceptionHandle] ex", e);
        return new ErrorResult("BAD", e.getMessage());
        // @ExceptionHandler와 ExceptionHandlerExceptionResolver는 해당 controller가 @RestController인 것을 보고 해당 객체 값을 json으로 반환한다.
    }

    @ExceptionHandler // public의 params와 동일한 예외인 경우 생략 가능
    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); // status setting을 ResponseEntity 내부에서 설정
    }

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler
    public ErrorResult exHandle(Exception e) { // 위에서부터 params에 들어가는 예외는 해당 예외부터 자손 예외까지 포함한다.
        log.error("[exceptionHandle ex]", e);
        return new ErrorResult("EX", "내부 오류");
    }
}

 

• controllerAdive 적용 범위 3가지

// 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 {}

 

 

분량이 많아서 아직 많이 헷갈린다. 꼭 9. API 예외 처리 pdf 같이 보면서 복습할 것