Spring ExceptionResolver

Springboot가 제공하는 ExceptionResolver가 존재하는데 HandlerExceptionResolverComosite에 다음 순서로 등록된다. (우선순위)

1. ExceptionHandlerExceptionResolver

2. ResponseStatusExceptionResolver → 개발자가 응답 코드 변경

3. DefaultHandlerExceptionResolover → 스프링 내부에서 자체적으로 처리

예외가 ExceptionHandlerExceptionResolver에서 처리되면 이후의 resolver는 진행되지 않고 null이 반환될 경우 다음 resolver를 호출한다.

ResponseStatusExceptionResolver

예외에 따라서 HTTP 상태 코드를 지정하는 resolver이다.

• @ResponseStatus 어노테이션이 있는 예외

• ResponseStatusException 예외

@ResponseStatus

@ResponseStatus(code = HttpStatus.XXX, reasone = "error message")
public class CustomExcpeiton extends RuntimeException {
   ...
}

정의한 클래스를 넘겨주면, 상태 코드와 에러 메시지를 내부적으로 response.sendError()에 넣어주고 ModelAndView()를 return 한다.

ResponseStatusException

@ResponseStatus 어노테이션은 개발자가 변경할 수 없는 곳에는 적용할 수 없다. 어노테이션을 작성해야 하는데, 코드를 수정할 수 없는 라이브러리의 예외 코드 같은 곳에 적용이 불가능하다.

이때는 ResponseStatusException 예외를 사용한다.

@GetMapping()
public String responseStatus() {
   throw new ResponseStatusException(
	HttpStatus.XXX, "error message", new IllegalArgumentException()
   );
   return "";
}

위의 두 경우 전부 ResponseStatusExceptionResolver가 예외를 처리해준다.

• 예외를 처리할 때 내부의 doResolveException()이 호출됨.

public ResponseStatusExceptionResolver 
      extends AbstracHandlerExceptionResolver  ... {
	 
    ...
 
    @Override
    @Nullable
    protected ModelAndView doResolverException(...) {
	 ...
	 sendError(statusCode, reason);
	 return new ModelAndView();
    }     
}

DefaultHandlerExceptionResolover

스프링 내부에서 발생하는 스프링 예외를 해결하는 resolver이다.

대표적으로 파라미터 바인딩 시점에 타입이 맞지 않으면 내부에서 TypeMismatchException이 발생하는데, 예외를 처리하지 않으면 서블릿 컨테이너까지 전달되고 500 에러를 반환한다.

파라미터 바인딩은 대부분 클라이언트가 HTTP 요청 정보를 잘못 호출해서 발생하는데, 이런 경우 HTTP 상태 코드 400을 사용하게 되어있다.

이 resolver는 이것을 500이 아니라 400으로 반환하도록 변경한다.

public class DefaultHandlerExceptionResolver 
			extends AbstractHandlerExceptionResolver {
			
   @Override
   @Nullable
   protected ModelAndView doResolveException(...) {
	...
	if (ex instanceof ConversionNotSupportedException theEx) {
			return handleConversionNotSupported(theEx, request, response, handler);
	}
	else if (ex instanceof TypeMismatchException theEx) {
		return handleTypeMismatch(theEx, request, response, handler);
	}
	else if () ....

	return null;
   }

   protected ModelAndView handleTypeMismatch(...) {
	response.sendError(HttpServletResponse.SC_BAD_REQUEST);
	return new ModelAndView();
   } 
}

handleTypeMismatch()의 내부에서는 send.Error(SC_BAD_REQUEST)를 호출한다.

위와 같은 HandlerExceptionResolver들을 직접 사용하기 복잡하다. API 오류에는 response.sendError()를 통해 직접 데이터를 넣어야 하고, ModelAndView를 리턴하는 것도 적합하지 않다.

스프링은 이것을 해결하기 위해 @ExceptionHandler라는 예외 처리 기능을 제공한다.

이것을 제어하는 것이 ExceptionHandlerExceptionResolver이다.

@ExceptionHandler

예외에 대한 별도의 설정이 없으면 BasicErrorController로 전달된다.

이렇게 BasicErrorController를 사용하거나 HandlerExceptioResolver를 구현하는 방식은 모든 API 에러를 제어하기 쉽지 않다.

• resolver를 구현하면 json 형태로 변환하고, HttpServletResponse에 직접 응답 데이터를 넣어주고, ModelAndView를 반환했다.

• 위 방식은 다른 도메인 컨트롤러에서 발생하는 같은 Exception(RuntimeException 같은)을 다른 형태로 다루기 어렵다.

스프링은 이 문제를 해결하기 위해서 @ExceptionHandler를 사용해서ExceptionHandlerExceptionResolver를 동작한다.

@RestController
public class ApiController {
   
   @ExceptionHandler(IllegalArgumentException.clss)
   public ErrorResult handler1(IllegalArgumentException ex) {
      return new ErrorResult(...);
   }
   
   // 동일하게 동작
   @ExceptionHandler
   public ErrorResult handler1(IllegalArgumentException ex) {
      return new ErrorResult(...);
   }
   
   @GetMapping() {
   public String causeException() {
     throw new IllegalArgumentException();
	   return "";
   }
}

예외가 발생하면 ExceptionHandlerResolver가 컨트롤러에서 @ExceptionHandler가 존재하는지 탐색한다.

존재한다면 실행하고 정상적인 흐름으로 바꿔서 return한다. 예외가 발생했지만, 정상 흐름으로 반환하면 상태 코드를 200으로 전달한다. (예외는 처리함.)

• 정상 흐름으로 바뀌면, 서블릿 컨테이너에 예외를 전달하고 서블릿 컨테이너에서 다시 에러 처리 요청을 보내고 그러지 않는다.

따라서 상태 코드도 변경하고 싶으면 @ResponseStatus()를 사용한다.

@ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(IllegalArgumentException.clss)
public ErrorResult handler1(IllegalArgumentException ex) {
  return new ErrorResult(...);
}