스프링 부트가 기본으로 제공하는(등록하는) ExceptionResolver에 대해 계속 알아보자.. 1. ExceptionHandlerExceptionResolver : @ExceptionHandler 처리 2. ResponseStatusExceptionResolver : Http 상태코드 지정할 수 있는 @ResponseStatus 처리 3. DefaultHandlerExceptionResolver : 스프링 내부 기본 예외 처리 위 순서대로 우선순위가 있다. (1번 return null이면 다음 ExceptionResolver인 2번이 호출되는 식) 이번엔.. 첫번째 우선순위를 가진.. ExceptionHandlerExceptionResolver에 대해 알아보자. BasicErrorController..

스프링 부트가 기본으로 제공하는(등록하는) ExceptionResolver에 대해 계속 알아보자.. 1. ExceptionHandlerExceptionResolver : @ExceptionHandler 처리 2. ResponseStatusExceptionResolver : Http 상태코드 지정할 수 있는 @ResponseStatus 처리 3. DefaultHandlerExceptionResolver : 스프링 내부 기본 예외 처리 위 순서대로 우선순위가 있다. (1번 return null이면 다음 ExceptionResolver인 2번이 호출되는 식) 이번엔.. DefaultHandlerExceptionResolver에 대해 알아보자. 스프링 내부에서 발생되는 예외를 해결해준다. BindingResul..

이전 포스팅까지... HandlerExceptionResolver를 직접 상속받으며 활용하는 방법을 알아봤다.. -> 개발량도 많고 개발하기에 불편한 점이 많았다.. 이러한 문제를 해결해주는.. 스프링 부트가 기본으로 제공하는(등록하는) ExceptionResolver에 대해 알아보자.. 1. ExceptionHandlerExceptionResolver : @ExceptionHandler 처리 2. ResponseStatusExceptionResolver : Http 상태코드 지정할 수 있는 @ResponseStatus 처리 3. DefaultHandlerExceptionResolver : 스프링 내부 기본 예외 처리 위 순서대로 우선순위가 있다. (1번 return null이면 다음 ExceptionR..

예외처리 6번 포스팅에서는 일반적인 예외가 발생했을때 HandlerExceptionResolver를 활용하여 sendError로 정상 리턴되면서 WAS가 알아볼 수 있도록 새로운 예외를 만들어주고 상태코드를 변경해줄 수 있었다. 또한, HttpServletResponse 파라미터를 활용하여 응답을 직접 구성해줘서 그대로 응답으로 내려주는 가능성도 보인다. 코드로 알아보자.. 개발자가 UserException이라는 새로운 예외를 만들었고 해당 예외를 처리 해줄 수 있는 HandlerExceptionResolver를 구현하였다. 해당 예외가 발생했다면 응답 상태코드로 400을 내려주도록 하였다. BasicErrorController에서 벗어나보자.. -> 요청 header의 accept가 applicatio..

이전 포스팅에서 확인했을 때, 예외가 발생했을 때, BasicErrorController 에서 제공해주는 Json 응답 기능은 편리하다. 하지만.. 아래는 현재까지 문제점이다. 1. 일반 예외의 경우 Http status 조절을 못한다. (sendError의 경우 조절 가능) 2. 개발자가 정한 사양대로의 응답 데이터로 못 내려준다. (BasicErrorController가 기본으로 제공하는 응답 json 데이터가 내려감) (물론 1, 2번 모두 BasicErrorController를 확장하면 가능하다..) HandlerExceptionResolver를 이용하여 위 문제를 해결해보자 일반 예외가 발생하였을 땐.. 기본적으로 WAS에서는 500 Status 값으로 처리된다. 이를 400으로 바꿔 보겠다....

이번엔 API 응답의 경우 예외처리 방법에 대해 알아보자.. (html 응답의 경우 특정 경로에 400대, 500대 오류페이지만 만들어주면 됐었다..) 예외가 발생 했을 때.. HTTP API 응답 보통 요청을 보낼때 HTTP header에 accept 값으로 application/json 으로 들어온다. 서블릿을 이용할 경우.. accept 가 다르게 들어오는것을 활용하여.. 전용 컨트롤러를 만들어준다. 예외처리 2번 포스팅의 ErrorPage 객체를 등록해주는 WebServerFactoryCustomizer 구현체의 연장선이다. produces 요소를 활용하여 요청 Http header의 accept가 application/json 인 경우에 적용되는 컨트롤러로 만들어준다. jackson 라이브러리는..

예외처리 1~3 포스팅에서.. 서블릿 컨테이너가 처리할 수 있는 예외 케이스와 개발자가 보여주고 싶은 에러 페이지를 어떻게 보여줄 수 있는지와 에러페이지 출력을 위한 내부 호출시.. 필터와 인터셉터를 적용 할지말지를 어떻게 처리하는지에 대해 알아 봤다.. 스프링 부트는 위와 같은 복잡한 방법을 간단하게 개발 할 수 있도록 지원해준다. WebServerFactoryCustomizer의 구현체 만들기, 에러페이지 출력을 위한 컨트롤러 개발에 대한 이야기이다. (필터, 인터셉터는 다른 이야기이다..) 이전 포스팅에서 구현한 ErrorPage(객체) 등록은 ErrorMvcAutoConfiguration 에서 처리 하며 상태코드에 따른 구현한 에러페이지(뷰 - html) 매핑 컨트롤러는 BasicErrorCont..

지금까지 예외처리에 대한 포스팅을 보면... WAS - 컨트롤러 간에 왔다갔다 하면서 중간에 있는 필터와 인터셉터가 계속 중복으로 호출된다... 경우에 따라.. 필터와 인터셉터는 중복으로 호출되면 안되는 경우도 있을 것이다.. -> 예를 들면 로그인 체크 로직을 위한 필터나 인터셉션은 이미 최초 정상요청에 의한 호출 로직에서 검증을 했을 것이나.. 에러페이지 출력을 위한 내부 호출에서 불필요한 검증을 하게된다. 그래서 정상요청에 의한 호출인지.. 에러페이지 출력을 위한 내부 호출인지 구분이 필요하다. -> DispatcherType을 사용해보자 DispatcherType 서블릿이 지원하는 enum 이다. REQUEST : 정상요청에 의한 호출일 경우 ERROR : 에러페이지 출력을 위한 내부 호출일 경우..