Spring MVC 마스터하기 예외처리 8

이전 포스팅까지...

HandlerExceptionResolver를 직접 상속받으며 활용하는 방법을 알아봤다..

-> 개발량도 많고 개발하기에 불편한 점이 많았다..

 

이러한 문제를 해결해주는..

스프링 부트가 기본으로 제공하는(등록하는) ExceptionResolver에 대해 알아보자..

1. ExceptionHandlerExceptionResolver : @ExceptionHandler 처리

2. ResponseStatusExceptionResolver : Http 상태코드 지정할 수 있는 @ResponseStatus 처리

3. DefaultHandlerExceptionResolver : 스프링 내부 기본 예외 처리

위 순서대로 우선순위가 있다.

(1번 return null이면 다음 ExceptionResolver인 2번이 호출되는 식)

 

ResponseStatusExceptionResolver

아래 두가지 경우를 처리해준다.

- 개발자가 만든 Exception에 @ResponseStatus가 달려있는 경우..

- ResponseStatusException 예외 자체를 생성하여 던질 경우

 

 

@ResponseStatus를 사용한 예외

위와 같이 개발자가 예외를 정의할 때, @ResponseStatus 어노테이션을 사용해준다.

(예제에선 RuntimeException을 상속받아 사용하도록 함.)

이렇게 정의를 해놓고 컨트롤러에서 이 예외가 터지도록 해놓으면..

원래 예외는 500으로 처리되지만 @ResponseStatus로 400 리턴되게 해놨기 때문에 400으로 적용된다.

reason은 예외 메세지이다.

 

 

ResponseStatusException 예외 자체를 생성하여 던질 경우

위와 같이 응답 상태코드(예시 404)와 예외 메세지, 실제 예외를 파라미터로 하여 생성하면 된다.

@ResponseStatus를 사용한 개발자 정의 예외 방법을 통해서는..

시스템, 라이브러리에서 제공하는 예외는 코드를 못고치기 때문에 제약이 있다..

그래서 ResponseStatusException 을 생성하는 방법으로 사용하면 된다.

(예시에서 IllegalArgumentException을 처리하는 것을 볼 수 있다.)

 

 

위 두가지 경우에 대해 ResponseStatusExceptionResolver가 동작되는 과정을 알아보자

위 코드는 ResponseStatusExceptionResolver의 doResolveException 메서드이다.

ResponseStatusExceptionResolver는 HandlerExceptionResolver를 구현하고 있다.

HandlerExceptionResolver의 ResolveException메서드가 호출되면 doResolveException이 호출된다.

 

ResponseStatusException 예외 자체를 생성하여 던질 경우에는

resolveResponseStatusException 메서드가 호출되며

 

@ResponseStatus를 사용한 예외가 처리될 때는

resolveResponseStatus 메서드가 호출된다.

 

<순서>

 예외가 터짐

-> ResponseStatusExceptionResolver가 처리시도한다. (우선순위 2번째)

-> doResolveException 메서드 호출

-> ResponseStatusException 예외 인지.. @ResponseStatus 어노테이션이 있는 예외 인지..

-> 첫번째 예외라면 resolveResponseStatusException메서드 호출

-> 두번째 예외라면 resolveResponseStatus 메서드 호출

-> 상태코드, 메세지 얻기

-> applyStatusAndReason 메서드 호출

-> sendError로 WAS가 알수있게 예외를 만들어주고, 빈 ModelAndView를 생성하여 정상 리턴

 

결국 컨트롤러에서 만들어진 예외가 ResponseStatusExceptionResolver를 통해 예외가 먹히고

response.sendError로 처리 되는 것을 알 수 있다.

 

주의 : sendError로 처리 하였기 때문에 WAS에서 다시 BasicErrorController가 호출될 것이다...

(BasicErrorController에서 accept에 따라 분기 되어 처리 됨)

 

<참고>

2가지 경우에 따른 예외 등록 및 생성 시, reason 요소 및 예외 메세지 파라미터에

error.bad 와 같이 입력 해두고 messages.properties와 같은 properties에서 메세지 관리 가능

(applyStatusAndReason 메서드에서 messageSource를 활용하여 찾는 것을 볼 수 있다.)