# HandlerExceptionResolver

ksk7584

ExceptionResolver 디스페처 서블릿은 컨트롤러에서 발생한 예외를 처리하기 위한 ExceptionResolver를 제공한다. 여기서 처리되지 않고 WAS까지 예외가 전달되면 뷰 템플릿을 찾기 위해 내부적으로 다시 컨트롤러까지 호출되는 일이 발생한다. 이는 컨트롤러는 물론, 필터와 인터셉터까지 재호출이 되기 때문에 비효율적인 동작이 추가되어 버린다. ExceptionResolver는 이 현상을 방지하고자 컨트롤러에서 발생한 예외를 해결하기 위해 ViewResolver나 HttpConverter이 호출되기 전에 ExceptionResolver를 호출하여 적절한 처리를 하게 한다. 인터셉터를 통해 컨트롤러에서 발생한 예외처리를 하려고 하면 preHandler나 afterCompletion에

imcool2551

본 글은 인프런 김영한님의 스프링 완전 정복 로드맵을 기반으로 정리했습니다. 0. 들어가며 예외 처리는 애플리케이션의 매우 중요한 부분입니다. MVC 예외 처리는 서블릿의 기능을 사용할 수도 있고 스프링 부트가 제공하는 기능을 사용할 수도 있습니다. 먼저, 서블릿이 제공하는 기능을 살펴보며 내부적인 원리를 살펴본 다음, 스프링 부트가 제공하는 기능의 편리함을 이용하는 방향으로 글을 정리했습니다. API의 경우 예외처리를 할 수 있는 방법이 다양하기 때문에 따로 정리했습니다. 1. MVC 예외처리 with 서블릿 웹 애플리케이션은 사용자 요청마다 쓰레드가 할당되고, 쓰레드는 서블릿 컨테이너 내부의 서블릿을 이용해서 실행된다. 전형적인 스프링 애플리케이션의 경우 서블릿을 디스패쳐 서블릿으로 이해하면 된다. 만약, 쓰레드 실행중에 예외가 발생했는데 try-catch 로 잡지 못하고 서블릿 밖으로 예외가 세어나가면 결국 톰캣같은 WAS 까지 예

gillog

#import 토비의 스프링 3.1 vol.2 스프링의 기술과 선택 현재 개발하고 있는 프로젝트단에서 JWT를 활용한 인증이 필요한 Handler를 공통적으로 인증 과정을 수행하는 HandlerInterceptorAdapter를 상속받는 JwtInterceptor를 위와 같이 사용하고 있었다. 위 인증 과정 중 인증 실패시 아래 처럼 Exception을 throw 하는 부분이 있는데, 해당 프로젝트에서 @ControllerAdvice를 통해서 공통으로 Exception을 Handling 하고 있던 상황이라, 정상적으로 Exception Handling이 수행되고 있다고 생각하고 있었다. ![](https://images.velog.io/images/gillog/post/1ad53e3a-c35

gmtmoney2357

본 게시물은 스스로의 공부를 위한 글입니다. 틀린 내용이 있을 수 있습니다. HTML 예외처리, 오류 페이지 설정 보러가기 📒HTML 오류 페이지 VS API 오류 메시지 HTML 오류 페이지야 그냥 고객 친화적으로 이쁘게 만들어서 보여주면 되지만, API오류는 다른 차원의 이야기이다. 예를 들어 상품과 관련된 API에서 발생하는 오류와 로그인 관련된 API에서 발생하는 오류 처리를 다르게할 필요가 있을 수 있다. 주로 클라이언트와 API 오류 스팩을 정해놓고 이에 맞춘다. 예를 들어서, 상품 페이지 요청 오류의 경우 다음과 같은 API