🌱 Spring MVC (13) 오류 페이지처리 (예외 처리)

Github 소스코드

🔎 Spring MVC에서 예외를 발생시키는 방법

예외를 발생시키는 두 가지 방법입니다.

• 첫 번째는 throw를 이용해 직접 예외 클래스를 동작시키는 방법입니다.
  • throw new RuntimeException("에러 에러");
• 두 번째는 HttpServletResponse의 sendError 메서드를 이용해 예외를 발생시키는 것 방법입니다.
  • response.sendError(404, "404에러 발생 메시지");

테스트를 위해 위 두 가지 방법을 이용해 여러 예외를 발생시켰습니다.
만약 아무런 처리를 하지 않는다면 Spring에서 기본으로 제공하는 White Lable 에러가 발생할 것 입니다.

@Slf4j
@Controller(value = "/error-page")
public class ExceptionController {

    @RequestMapping("/error-boom")
    public String errorRuntime() {
        throw new RuntimeException("에러 에러");
    }

    @RequestMapping("/error-404")
    public void error404(HttpServletResponse response) throws IOException {
        response.sendError(404, "404 에러 발생 메시지");
    }

    @RequestMapping("/error-400")
    public void error400(HttpServletResponse response) throws IOException {
        response.sendError(400, "400 에러 발생 메시지");
    }

    @RequestMapping("/error-403")
    public void error403(HttpServletResponse response) throws IOException {
        response.sendError(403, "403 에러 발생 메시지");
    }

    @RequestMapping("/error-500")
    public void error500(HttpServletResponse response) throws IOException {
        response.sendError(500, "500 에러 발생 메시지");
    }
}

---

🔎 Spring에서 예외의 흐름

예외가 발생했을 때 예외가 발생한 메서드 혹은 클래스에서 try-catch 등으로 예외를 잡아주지 않는다면 자신을 호출한 메서드 혹은 클래스로 예외를 던지게 됩니다.

예외를 전혀 잡지 않은 시나리오를 한 번 살펴볼께요.
1. 컨트롤러에서 RuntimeException 발생
2. 컨트롤러는 자신을 호출한 인터셉터로 예외를 던짐
3. 인터셉터는 자신을 호출한 서블릿 컨테이너에 예외를 던짐(Dispatcher servlet)
4. 서블릿 컨테이너는 필터로 예외를 던짐
5. 필터는 WAS로 예외를 던짐

여기서 중요한 것은 예외가 WAS까지 전파된다는 것 입니다.
WAS는 전파받은 예외를 더 이상 던지지 않고 자기가 처리합니다.
처리 방식이 중요한데 전파된 WAS는 에러코드를 보고 오류 페이지 출력을 위해 어떤 URL을 만들어서 다시 특정 컨트롤러에 요청합니다.

어떤 URL일까요?

SpringBoot를 사용하는 경우 WAS까지 도달하는 예외에 대해서 WAS는 /error에 예외정보를 담아 요청합니다. SpringBoot는 기본적으로 BasicErrorController에서 /error에 대한 처리를 합니다.

BasicErrorController는 자신에게 온 요청을 처리합니다.
특히 에러 페이지를 랜더링해주는 기능을 수행합니다.

500에러가 발생했다고 해볼께요.
BasicErrorController 가 에러페이지를 랜더링하는 정책이 정해져있습니다.

• 1. templates/error/500.html 을 찾아 랜더링
• 2. templates/error/5xx.html을 찾아 랜더링
• 3. static/error/500.html을 찾아 랜더링
• 4. static/error/5xx.html을 찾아 랜더링
     

스프링은 언제나 구체적인 것이 우선순위를 갖습니다. 5xx보다는 500이 구체적이기 때문에 우선순위를 갖는 것 입니다.

우리는 이렇게 간단하게 특정 경로에 정책에 맞는 html을 만들어주기만 하면 서블릿 밖으로 날라가는 에러에 대해 적합한 에러 페이지를 보여줄 수 있습니다.

---

🔎 WAS에서 예외처리시 필터, 인터셉터가 중복 호출되는 문제

• 
• 

위 그림을 다시 볼께요.
발생한 예외를 서블릿 이전에서 처리하지 못하고 WAS까지 넘어간 경우 WAS는 다시 오류 페이지를 요청하는 구조입니다.

다시 오류 페이지를 요청하는 구조에서 의미없는 필터, 인터셉터 등이 호출될 수 있습니다. 여기서 의미가 없다는 것은 로그인 검증 필터 등이 해당합니다. 이미 검증을 마친 사용자의 요청을 수행하고 있는데 발생한 예외이고 서버 내부적으로 처리하는 것 뿐인데 다시 검증 필터 혹은 인터셉터의 검증을 받을 필요가 있을까요?

반대의 상황도 있을 수 있습니다.
WAS에서 오류 처리에 의한 호출인 경우에만 동작시킬 필터, 인터셉터 등이 있을 수도 있는 것이죠.

어떻게 예외처리로 인한 에러 페이지 요청인지, 정상적인 사용자의 요청인지 구분할 수 있을까요 ?

WAS의 요청에는 DispatcherType이라는 추가정보가 제공됩니다.

DispatcherType 타입 종류
1. REQUEST: 클라이언트의 요청
2. ERROR: 에러 페이지 요청
INCLUDE, FORWARD 등이 더 있지만 사용하고자 하는 것만 알아둘께요.

---

🔎 Filter에서 Dispatcher 타입 구분

Filter는 등록시 Dispatcher Type을 구분할 수 있습니다.
제공되는 setDispatcherTypes 메서드로 필터를 적용시킬 Dispatcher Type을 정의합니다.

아래 코드는 정의한 Filter를 빈으로 등록하는 작업을 합니다.
setDispatcherTypes 부분을 보면 DispatcherType.REQUEST, DispatcherType.ERROR을 설정해주었습니다.
사용자의 요청, 에러페이지 요청에 모두에 등록하는 필터를 적용시키겠다는 것이지요.

@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Bean
    FilterRegistrationBean<Filter> getLogFilter() {
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new LogFilter());
        filterRegistrationBean.setOrder(1);
        filterRegistrationBean.addUrlPatterns("/*");
       
        filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);

        return filterRegistrationBean;
    }
}

만약 사용자의 요청에 대해서만 필터를 적용시키고 싶다면 아래와 같이 DispatcherType.ERROR를 빼주면 됩니다.

filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST);

---

🔎 Interceptor에서 Dispatcher 타입 구분

이전 인터셉터를 다룬 포스트에서 사용했던 excludePathPatterns를 사용합니다.

WAS는 예외 페이지 요청을 위해 BasicErrorController에 매핑되어 있는 /error로 요청을 보낸다고 했습니다.

/error 요청 자체를 excludePathPatterns로 설정하고자 하지 않는다면 WAS의 에러 페이지 요청에 인터셉터를 동작시키거나 동작시키지 않거나 할 수 있습니다.

@Override
public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(new LogInterceptor())
            .order(1)
            .addPathPatterns("/**")
            .excludePathPatterns("/css/**", "/error"); 
    }

---

인프런 김영한님의 스프링 MVC 2편 을 수강하고 정리한 내용입니다.