서블릿 예외 처리

이선우·2024년 9월 22일
0

개발 관련 지식

목록 보기
7/13
post-custom-banner

서블릿은 2가지 방식으로 예외 처리를 지원한다

  • Exception
  • response.sendError(HTTP 상태 코드, 오류 메시지)

Exception(예외)

자바의 메인 메서드를 실행 ->main이라는 이름의 쓰레드가 실행
실행 도중에 예외를 잡지 못하면 -> 예외 정보를 남기고, 해당 쓰레드는 종료된다.

웹 애플리케이션

웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다.
애플리케이션에서 예외가 발생했을 때, 어디선가 try ~ catch로 예외를 잡아서 처리하면 아무런 문제가 없다. 그러나 예외를 잡지 못하고, 서블릿 밖으로 까지 예외가 전달하면 아래와 같이 동작한다.

서블릿

여기서 서블릿이란 간단하게 말하면 Java를 기반으로 한 웹 애플리케이션을 개발할 때 서버 측에서 클라이언트의 요청을 처리하고 그에 대한 응답을 생성하는 자바 클래스이다. 웹 서버에서 실행되며, 클라이언트로부터의 HTTP 요청을 받아 적절한 비즈니스 로직을 수행하고, 결과를 HTTP 응답으로 반환하는 역할을 한다.

WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)

결국 톰캣 같은 WAS까지 예외가 전달된다.

 @Controller
 public class ServletExController {
     @GetMapping("/error-ex")
     public void errorEx() {
throw new RuntimeException("예외 발생!"); }
}

위 url을 실행하면 HTTP 상태 코드 500이 반환된다.
-> Exception의 경우 서버 내부에서 처리할 수 없는 오류가 발생한 것으로 생각되어 상태 코드 500이 반환된다.

response.sendError(HTTP 상태코드, 오류 메시지)

이것은 호출한다고 당장 예외가 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다.

@GetMapping("/error-500")
 public void error500(HttpServletResponse response) throws IOException {
     response.sendError(500);
 }

WAS(sendError 호출 기록 확인) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러 (response.sendError())

response 내부에서 오류가 발생했다는 상태를 저장해둔다.
그리고 서블릿 컨테이너는 고객에게 응답 전에 response
sendError()가 호출되었는지 확인한다. 그리고 호출 되었다면 설정한 오류 코드에 맞추어 기본 오류 페이지를 보여준다.

서블릿 컨테이너

여기서 서블릿 컨테이너가 무엇인지 간단히 말하자면

서블릿 컨테이너는 서블릿이라는 프로그램을 관리하고 실행하는 역할을 하는 곳으로, 서블릿을 실행하고, 클라이언트의 요청을 받아서 서블릿에게 전달하고, 서블릿이 처리한 결과를 다시 클라이언트에게 보내주는 일을 한다.

오류 화면 제공

서블릿 컨테이너가 제공하는 기본 예외 처리 화면은 고객 친화적이지 않다.

과거에는 web.xml이라는 파일에 오류화면을 등록했다.

 <web-app>
     <error-page>
     <error-code>404</error-code>
     <location>/error-page/404.html</location>
     </error-page>
     <error-page>
     <error-code>500</error-code>
     <location>/error-page/500.html</location>
     </error-page>
     <error-page>
     <exception-type>java.lang.RuntimeException</exception-type>
     <location>/error-page/500.html</location>
     </error-page>
 </web-app>

지금은 스프링 부트를 통해서 서블릿 컨테이너를 실행하기 때문에 스프링 부트의 기능을 사용할 수 있다.

package hello.exception;
 import org.springframework.boot.web.server.ConfigurableWebServerFactory;
 import org.springframework.boot.web.server.ErrorPage;
 import org.springframework.boot.web.server.WebServerFactoryCustomizer;
 import org.springframework.http.HttpStatus;
 import org.springframework.stereotype.Component;
@Component
 public class WebServerCustomizer implements
 WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
     @Override
     public void customize(ConfigurableWebServerFactory factory) {
         ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-
 page/404");
         ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR,
 "/error-page/500");
ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-
page/500");
         factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
} }

response.sendError(404): errorPage404 호출
response.sendError(500): errorPage500 호출
RuntimeException 또는 그 자식 타입의 예외: errorPageEx 호출

@Slf4j
 @Controller
 public class ErrorPageController {
     @RequestMapping("/error-page/404")
     public String errorPage404(HttpServletRequest request, HttpServletResponse
 response) {
         log.info("errorPage 404");
         return "error-page/404";
     }

오류를 처리할 컨트롤러이다.

오류 페이지 작동 원리

서블릿은 Exception이 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError()가 호출 되었을 때 설정된 오류 페이지를 찾는다.

WAS는 해당 예외를 처리하는 오류 페이지 정보를 확인한다.

중요한 점은 웹 브라우저(클라이언트)는 서버 내부에서 이런 일이 일어나는지 전혀 모른다. 오직 서버 내부에서 오류 페이지를 찾기 위해 추가적인 호출을 한다.

  1. 예외가 발생해서 WAS까지 전파된다.
  2. WAS는 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다. 이때 오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다.

오류 정보 추가

WAS는 오류 페이지를 단순히 다시 요청만 하는 것이 아니라, 오류 정보를 request의 attribute에 추가해서 넘겨준다.

public static final String ERROR_EXCEPTION =
"javax.servlet.error.exception";
    public static final String ERROR_EXCEPTION_TYPE =
"javax.servlet.error.exception_type";
    public static final String ERROR_MESSAGE = "javax.servlet.error.message";
    public static final String ERROR_REQUEST_URI =
"javax.servlet.error.request_uri";
    public static final String ERROR_SERVLET_NAME =
"javax.servlet.error.servlet_name";
    public static final String ERROR_STATUS_CODE =
"javax.servlet.error.status_code";
    @RequestMapping("/error-page/404")
    public String errorPage404(HttpServletRequest request, HttpServletResponse
response) {
        log.info("errorPage 404");
        printErrorInfo(request);
        return "error-page/404";
}

private void printErrorInfo(HttpServletRequest request) {
        log.info("ERROR_EXCEPTION: ex=", request.getAttribute(ERROR_EXCEPTION));
        log.info("ERROR_EXCEPTION_TYPE: {}",
request.getAttribute(ERROR_EXCEPTION_TYPE));
        log.info("ERROR_MESSAGE: {}", request.getAttribute(ERROR_MESSAGE)); //ex
        의 경우 NestedServletException 스프링이 한번 감싸서 반환 log.info("ERROR_REQUEST_URI: {}", request.getAttribute(ERROR_REQUEST_URI));
         log.info("ERROR_SERVLET_NAME: {}",
 request.getAttribute(ERROR_SERVLET_NAME));
         log.info("ERROR_STATUS_CODE: {}",
 request.getAttribute(ERROR_STATUS_CODE));
         log.info("dispatchType={}", request.getDispatcherType());
     }
}

필터

로그인 인증 체크 같은 경우를 생각해보면, 이미 한번 필터나, 인터셉터에서 로그인 체크를 완료했다. 따라서 서버 내부에서 오류 페이지를 호출한다고 해서 해당 필터나 인터셉트가 한번 더 호출되는 것은 매우 비효율적이다.
결국 클라이언트로 부터 발생한 정상 요청인지, 아니면 오류 페이지를 출력하기 위한 내부 요청인지 구분할 수 있어야 한다. 서블릿은 이런 문제를 해결하기 위해 DispatcherType이라는 추가 정보를 제공한다.

필터에 이런 경우를 위해서 dispatcherType 라는 옵션을 제공한다.

고객이 처음 요청하면 dispatcherType=REQUEST이다.
이렇듯 서블릿 스펙은 실제 고객이 요청한 것인지, 서버가 내부에서 오류 페이지를 요청하는 것인지 DispatcherType으로 구분할 수 있다.

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

인터셉터

앞서 필터의 경우에는 필터를 등록할 때 어떤 DispatcherType인 경우에 필터를 적용할 지 선택할 수 있었다. 그런데 인터셉터는 서블릿이 제공하는 기능이 아니라 스프링이 제공하는 기능이다. 따라서 DispatcherType과 무관하게 항상 호출된다.

대신에 인터셉터는 다음과 같이 요청 경로에 따라서 추가하거나 제외하기 쉽게 되어 있기 때문에, 이러한 설정을 사용해서 오류 페이지 경로를 excludePathPattern 를 사용해서 빼주면 된다.

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

스프링 부트 - 오류 페이지

스프링 부트는 모든 과정을 기본으로 제공한다

  • ErrorPage를 자동으로 등록한다. 이때 /error라는 경로로 기본 오류 페이지를 설정한다.
    - new ErrorPage("/error"), 상태코드와 예외를 설정하지 않으면 기본 오류 페이지로 사용된다.
    • 서블릿 밖으로 예외가 발생하거나, response.sendError()가 호출되면 모든 오류는 /error를 호출하게 된다.
  • BasicErrorController라는 스프링 컨트롤러를 자동으로 등록한다.
    - ErrorPage에서 등록한 /error를 매핑해서 처리하는 컨트롤러이다.

cf) ErrorMvcAutoConfiguration이라는 클래스가 오류 페이지를 자동으로 등록하는 역할을 한다.

BasicErrorController는 기본적인 로직이 모두 개발되어 있다. 개발자는 오류 페이지 화면만 BasicErrorController가 제공하는 룰과 우선순위에 따라서 등록하면 된다. 정적 HTML이면 정적 리소스, 뷰 템플릿을 사용해서 동적으로 오류 화면을 만들고 싶으면 뷰 템플릿 경로에 오류 페이지 파일을 만들어서 넣어두기만 하면 된다.

profile
이선우
백엔드 개발자 준비생
이전 포스트

싱글톤이란?

다음 포스트

API 예외 처리

post-custom-banner

0개의 댓글