서블릿 예외 처리
서블릿은 2가지 방식으로 예외 처리를 지원한다.
- Exception(예외)
- response.sendError(HTTP 상태 코드, 오류 메세지)
Exception(예외)
자바 직접 실행
자바의 메인 메서드를 직접 실행하는 경우 main이라는 이름의 쓰레드가 실행된다.
실행 도중에 예외를 잡지 못하고 처음 실행한 main()메서드를 넘어서 예외가 던져지면,
예외 정보를 남기고 해당 쓰레드는 종료된다.
예외가 터졌을 때 예외를 못잡으면 Exception은 계속 부모까지 올라간다
웹 애플리케이션
웹 애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서
실행된다.
애플리케이션에서 예외가 발생했는데, 어디선가 try ~ catch로 예외를 잡아서 처리하면
아무런 문제가 없다. 그런데 만약 애플리케이션에서 예외를 잡지 못하고, 서블릿 밖으로
까지 예외가 전달되면 어떻게 동작할까?
WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)결국 톰캣같은 WAS 까지 예외가 전달된다.
Exception
Exception의 경우 서버 내부에서 처리할 수 없는 오류가 발생한 것으로 생각해서
HTTP 상태코드 500을 반환한다
response.sendError(HTTP 상태 코드, 오류 메세지)
오류가 발생했을 때 HttpServletResponse가 제공하는 sendError라는 메서드를 사용해도 된다.
이것을 호출한다고 당장 예외가 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가
발생했다는 점을 전달할 수 있다.
이 메서드를 사용하면 HTTP 상태 코드와 오류 메세지도 추가할 수 있다.
- response.sendError(HTTP 상태 코드)
- response.sendError(HTTP 상태 코드, 오류 메세지)
sendError 흐름
WAS(sendError 호출 기록 확인) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(response.sendError())response.sendError()를 호출하면 response 내부에는 오류가 발생했다는 상태를 저장해둔다.
스리고 서블릿 컨테이너는 고객에게 응답 전에 response에 sendError()가 호출되었는지 확인한다.
그리고 호출 되었다면 설정한 오류 코드에 맞추어 기본 오류 페이지를 보여준다.
서블릿 예외 처리 - 오류 화면 제공
서블릿은 Exception(예외)가 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError()가 호출되었을 때 각각의 상황에 맞춘 오류 처리 기능을 제공한다.
이 기능을 사용하면 친절한 오류 처리 화면을 준비해서 고객에게 보여줄 수 있다.
서블릿 오류 페이지 등록
@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
@Override
public void customize(ConfigurableWebServerFactory factory) {
//HTTP 상태 코드로, 404일때, 500일때
ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
//500일때, RuntimeException 의 자식예외까지 다 보내줌
ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500");
factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
}
}- response.sendError(404) : errorPage404 호출
- response.sendError(500) : errorPage500 호출
- RuntimeException or 그 자식 타입의 예외 : errorPageEx 호출
오류 처리 컨트롤러
@Slf4j
@Controller
public class ServletExceptionController {
//예외
@GetMapping("/error-ex")
public void errorEx() {
throw new RuntimeException("예외 발생!");
}
@GetMapping("/error-404")
public void error404(HttpServletResponse response) throws IOException {
response.sendError(404,"404오류");
}
@GetMapping("/error-500")
public void error500(HttpServletResponse response) throws IOException {
response.sendError(500);
}
}서블릿 예외 처리 - 오류 페이지 작동 원리
서블릿은 Exception(예외)가 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError()가 호출되었을 때 설정된 오류 페이지를 찾는다.
예외 발생 흐름
WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)sendError 흐름
WAS(sendError 호출 기록 확인) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(response.sendError())WAS는 해당 예외 처리하는 오류 페이지 정보를 확인한다
new ErrorPage(RuntimeException.class, "/error-page/500")예를 들어 RuntimeException 예외가 WAS까지 전달되면, WAS는 오류 페이지 정보를 확인한다.
확인해보니 RuntimeException의 오류페이지로 /error-page/500이 지정되어 있다.
WAS는 오류 페이지를 출력하기 위해 /error-page/500 을 다시 요청한다.
오류 페이지 요청 흐름
WAS '/error-page/500' 다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/error-page/500) -> View예외 발생과 오류 페이지 요청 흐름
1. WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)
2.WAS '/error-page/500' 다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/error-page/500) -> View 중요한 점은 웹 브라우저(클라이언트)는 서버 내부에서 이런 일이 일어나는지 전혀 모른다.
오직 서버 내부에서 오류 페이지를 찾기 위한 추가적인 호출을 한다.
- 예외가 발생해서 WAS까지 전파된다.
- WAS는 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다.
이때 오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다.
서블릿 예외 처리 - 필터
예외 발생과 오류 페이지 요청 흐름
1. WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)
2.WAS '/error-page/500' 다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/error-page/500) -> View오류가 발생하면 오류 페이지를 출력하기 위해 WAS 내부에 다시 한번 호출이 발생한다.
이때 필터, 서블릿, 인터셉터도 모두 다시 호출된다. 그런데 로그인 인증 체크 같은 경우는
이미 한번 필터나, 인터셉터에서 로그인 체크를 완료했다. 따라서 서버 내부에서오류 페이지를
호출 한다고 해서 해당 필터나 인터셉트가 한번 더 호출되는 것은 매우 비효율적이다.
결국 클라이언트로 부터 발생한 정상 요청인지, 아니면 오류 페이지를 출력하기 위한
내부 요청인지 구분할 수 있어햐 한다. 서블릿은 이러한 문제를 해결하기 위해 DispatcherType이라는 추가 정보를 제공한다.
DispathcerType
- REQUEST : 클라이언트 요청
- ERROR : 오류 요청
- FORWARD : 서블릿에서 다른 서블릿이나 JSP를 호출할 때
- INCLUDE : 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때
- ASYNC : 서블릿 비동기 호출
서블릿 예외 처리 - 인터셉터
@Configuration
public class WebConfig implements WebMvcConfigurer {
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new LogInterceptor())
.order(1)
.addPathPatterns("/**")
.excludePathPatterns("/css/**", "*.ico", "/error", "/error-page/**"); //오류 페이지 경로
}
}전체 흐름 정리
/hello 정상 요청
WAS(/hello, dispatchType=REQUEST) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러 -> View/error-ex 오류 요청
- 필터는 DispatchType으로 중복 호출 제거(dispatchType=REQUEST)
- 인터셉터는 경로 정보로 중복 호출 제거(excludePathPatterns("error-page/**"))
1. WAS(/error-ex, dispatchType=REQUEST) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러
2. WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)
3. WAS 오류 페이지 확인
4. WAS(/error-page/500, dispatchType=ERROR) -> 필터(x) -> 서블릿 -> 인터셉터(x) ->
컨트롤러(/error-page/500) -> View스프링 부트 - 오류 페이지
