스프링이 아닌 순수 서블릿 컨테이너는 예외를 어떻게 처리하는지 알아보자
- Exception
- response.sendError
웹애플리케이션
웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 애플리케이션에서 예외가 발생했는데, try-catch로 못잡으면 서블릿 밖으로 까지 예외가 전달된다.
톰캣같은 WAS 까지 예외가 전달되게 된다.
이때 WAS는 이 예외를 어떻게 처리할까
response.sendError(src,msg)
response.sendError()를 호출하면 response내부에는 오류가 발생했다는 상태를 저장해둔다. 그리고 서블릿 컨테이너는 고객에게 응답 전에 response에 sendError()가 호출되었는지 확인한 후 호출되었다면 설정한 오류코드에 맞추어 기본 오류페이지를 보여준다.
서블릿 컨테이너가 제공하는 기본 예외 처리 화면은 사용작 ㅏ보기에 불편하다. 의미 있는 오류 화면을 제공해보자
서블릿 예외처리 - 오류 화면 제공
서블릿은 Exception이 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError()가 호출 되었을 때 각각의 상황에 맞춘 오류 처리 기능을 제공한다.
스프링 부트가 제공하는 기능ㅇ르 사용해서 서블릿 오류 페이지를 등록해보자
서블릿 오류 페이지 등록하기
@Component
public class WebServerCustomizer implements
WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
@Override
public void customize(ConfigurableWebServerFactory factory) {
ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/errorpage/404");
ErrorPage errorPage500 = new
ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/errorpage/500");
factory.addErrorPages(errorPage404, errorPage500, 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";
}
@RequestMapping("/error-page/500")
public String errorPage500(HttpServletRequest request, HttpServletResponse
response) {
log.info("errorPage 500");
return "error-page/500";
}
}서블릿 예외처리 - 오류 페이지 작동 원리
서블릿은 Exception이 발생해서 서블릿 밖으로 전달되거나 response.sendError()가 호출 되엇을 때 설정된 오류 페이지를 찾는다.
WAS는 해당 예외를 처리하는 오류 페이지 정보를 확인한다.
중요한 점은 웹 브라우저(클라이언트)는 서버 내부에서 이런 일이 일어나는지 전혀 모른다는 점이다. 오직 서버 내부에서 오류 페이지를 찾기 위해 추가적인 호출을 한다.
정리하면 다음과 같다
1.예외가 발생해서 WAS까지 전파된다.
2.WAS는 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다. 이때 오류 페이지 경로로 필터,서블릿,인터셉터,컨트롤러가 모두 다시 호출된다.
오류정보
WAS는 오류 페이지를 단순히 다시 요청만 하는 것이 아니라, 오류 정보를 request의 attribute에 추가해서 넘겨준다.!
필요하면 오류 페이지에서 전달된 오류 정보를 사용할 수 도 있다.
서블릿 예외 처리 - 필터
오류가 발생하면 오류 페이지를 출려갛기 위해 WAS에서 다시 한번 호출이 발생하게 된다. 이때 필터,서블릿,인터셉터도 모두 다시 호출되게 되는데
필터나 인터셉터 한번 더 호출되는거는 매우 비효율적이다. 따라서
클라이언트로부터 발생한 정상 요청인지, 아니면 오류 페이지를 출력하기 위한 내부 요청인지 구분할 수 있어야 한다. 서블릿은 이런 문제를 해결하기 위해 DispatcherType이라는 추가 정보를 제공한다.
DispatcherType
필터는 이런 경우를 위해서 dispatcherTypes라는 옵션을 제공한다.
고객이 처음 요청하면 dispatcherType=REQUEST이다.
서블릿 예외 처리 - 인터셉터
필터는 DispatcherType인 경우에 필터를 적용할 지 선택할 수 있었는데 인터셉터는 서블릿이 제공하는 기능이 아니라 스프릉이 제공하는 기능이므로 DispatcherType과 무관하게 항상 호출된다.
- 대신에 인터셉터는 요청경로에 따라서 추가하거나 제외하기 쉽게 되어있기 때문에 이러한 설정을 사용해서 오류 페이지 경로를 excludePathPatterns를 사용해서 빼주면 된다.
스프링 부트 - 오류 페이지1
지금까지는 webservercustomizer 를 만들고
예외 종류에 따라서 erropage를 추가하고
예외 처리용 컨트롤러 errorpagecontroller를 만들었다.
스프링부트는 이런 과정을 모두 기본으로 제공한다.
- ErrorPage를 자동으로 등록한다. 이때 /error라는 경로로 기본 오류 페이지를 설정함
- new ErrorPage("/error"), 상태코드와 예외를 설정하지 않으면 기본 오류 페이지로 사용된다.
- 서블릿 밖으로 예외가 발생하거나 ,response.sendError()가 호출되면 모든 오류는 /error를 호출하게된다.
- BasicErrorController라는 스플이 컨트롤러를 자동으로 등록한다.
- ErrorPage에서 등록한 /error를 매핑해서 처리하는 컨트롤러다.
이제 오류가 발생했을 때 오류 페이지로 /error를 기본 요청한다. 스프링 부트가 자동 등록한 BasicErrorController는 이 경로를 기본으로 받는다.
개발자는 오류 페이지만 등록하면 된다.
BasicErrorController는 기본적인 로직이 모두 개발되어있는 상태이다.
개발자는 오류 페이지 화면만 BasicErrorController가 제공하는 룰과 우선순위에 따라서 등록하면 된다. 정적 HTML이면 정적 리소스, 뷰 템플릿을 사용해서 동적으로 오류 화면을 만들고 싶으면 뷰 템플릿 경로에 오류 페이지 파일을 만들어서 넣어두기만 하면 된다.
뷰 선택 우선순위
- 뷰 템플릿
- resources/templates/error/500.html
- resources/templates/error/5xx.html
- 정적 리소스
- resources/static/error/400.html
- resources/static/error/404.html
- resources/static/error/4xx.html
- 적용 대상이 없을 때 뷰 이름(error)
- resources/templates/error.html
해당 경로 위치에 HTTP 상태 코드 이름의 뷰 파일을 넣어두면 된다.
뷰 템플릿이 정적 리소스보다 우선순위가 높고, 404, 500처럼 구체적인 것이 5XX처럼 덜 구체적인 것보다 우선순위가 높다.
