자바의 main 메서드를 직접 실행하는 경우 main 이라는 이름의 쓰레드가 실행되고 실행 도중 예외를 잡지 못해서 main 메서드를 넘어서 예외가 던져지면, 예외 정보를 남기고 쓰레드가 종료된다.
웹어플리케이션은 사용자 요쳥별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다. 만약에 예외가 발생했는데 컨트롤러에서 예외를 잡지 못하고 WAS까지 예외가 전달이 되면 서블릿 컨테이너가 기본으로 제공하는 오류 화면이 호출된다.
서블릿과 서블릿 컨테이너
더보기
CGI는 웹 서버와 웹 애플리케이션 서버(WAS) 간에 데이터를 주고 받기 위한 규악으로 서버 프로그램은 CGI 규약에 따라 클라이언트의 데이터를 환경변수로 전달하고, 프로그램의 표준 출력 결과를 클라이언트에게 전송한다.
서블릿은 자바 웹 서버가 동적인 페이지를 생성할 수 있도록 클라이언트의 요청을 처리하고, 결과를 반환하는 자바 웹 프로그래밍 기술로 흔히 자바로 구현된 CGI 라고 한다. 서블릿은 독립적으로 실행되지 않으며 서블릿 컨테이너에 의해 생명주기 관리가 되는데 대표적인 오픈 소스 서블릿 컨테이너로 톰캣(WAS)이 있다.
서블릿 컨테이너는 클라이언트와 서버 간의 소켓 통신에 필요한 TCP/IP 연결, HTTP 프로토콜 해석 등의 네트워크 기반 작업을 추상화해 API로 제공하여 복잡한 과정을 생략하고 개발자가 비즈니스 로직에 집중하게 도와준다.
서블릿 컨테이너는 서블릿 인터페이스(javax.servlet.Servlet)를 구현하여 GenericServlet 이라는 추상 클래스를 제공하는데 이는 service() 메서드를 제외하고 대부분의 서블릿에 필요한 메서드를 구현한 일종의 서블릿 어댑터이다.
일반적으로 알고 있는 서블릿인 HttpServlet은 GenericServlet을 상속 받아 추상 메서드인 service()를 HTTP 프로토콜 요청 메서드에 적합하게 구현한 서블릿으로 서블릿 컨테이너는 웹 서버로부터 요청을 받으면 HTTP 프로토콜로 request, response 객체를 생성하여 서블릿을 호출하고 service()를 실행한다.
참고)
https://yangbongsoo.gitbook.io/study/servlet_container
https://mangkyu.tistory.com/14
https://12bme.tistory.com/555
오류가 발생했을 때, HttpServletResponse가 제공하는 response.sendError(HTTP StatusCode, ErrorMessage)를 사용해서 서블릿 컨테이너에게 오류가 발생했다는 것을 전달할 수도 있다. 서블릿 컨테이너는 클라이언트에게 응답을 보내기 전 response 객체에 sendError()가 호출되었는지 확인하고 오류 페이지를 보여준다.
서블릿 컨테이너가 제공하는 기본 예외 처리 화면 대신 서블릿이 제공하는 오류 화면 기능을 사용하면 고객 친화적으로 오류 화면을 보여줄 수 있다. WebServerFactoryCustomizer의 customize를 오버라이드해서 오류 페이지를 등록할 수 있는데 HTTP 상태 코드와 오류 페이지 url로 ErrorPage를 생성해서 등록하고 오류 페이지를 처리할 컨트롤러를 생성하면 된다. (스프링 부트 자동화)
WAS는 ErrorPage를 확인하고 오류 정보를 request의 attribute에 담아서 오류 페이지 url로 다시 요청을 하는데 서버 내부에서 추가적인 호출을 하는 것이기 때문에 클라이언트는 알 수가 없다. 오류 페이지를 요청할 때 필터, 서블릿, 인터셉터가 전부 다시 호출되는데 서블릿은 해당 요청이 정상 요청인지, 오류 요청인지 알 수 있는 추가 정보로 DispatcherType(ENUM)을 제공한다.
(DispatcherType = FORWARD, REQUEST, ERROR ..)
// 필터를 등록할때 추가로 DispatcherType 설정 가능
// 기본 값이 REQUEST라서, 별도의 설정이 없으면 정상 요청시에만 필터를 적용한다.
filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);
필터는 위와 같이 등록 시 설정을 해주면 되지만 기본 설정이 오류 요청에는 필터를 적용하지 않는 것이라 문제가 없다. 인터셉터는 서블릿이 아닌 스프링이 제공하는 기능이기 때문에 DispatcherType을 이용할 수 없고 excludePathPatterns에 오류 페이지 경로를 넣어주면 된다.
스프링 부트는 ErrorPage를 '/error' 라는 기본 경로로 자동으로 등록하고 BasicErrorController라는 스프링 컨트롤러를 생성한다.
BasicErrorController는 기본 로직이 전부 등록되어 있기 때문에 해당 컨트롤러가 제공하는 규칙에 따라 오류 페이지를 등록만 해두면 된다. 그리고 오류 관련 정보를 model에 담아서 전달하기 때문에 뷰 템플릿은 이 값을 활용해서 출력할 수 있다.
옵션으로 오류 관련 정보를 보낼지 설정이 가능한데 실무에서는 오류 정보를 전송하는 것은 위험하기 때문에 사용하지 않는 것이 좋다.
<ul>
<li>오류 정보</li>
<ul>
<li th:text="|timestamp: ${timestamp}|"></li>
<li th:text="|path: ${path}|"></li>
<li th:text="|status: ${status}|"></li>
<li th:text="|message: ${message}|"></li>
<li th:text="|error: ${error}|"></li>
<li th:text="|exception: ${exception}|"></li>
<li th:text="|errors: ${errors}|"></li>
<li th:text="|trace: ${trace}|"></li>
</ul>
</li>
</ul>
server.error.include-exception=true
// never : 사용 x, always: 항상 사용, on_param : 파라미터가 있을 때 사용
server.error.include-message=on_param
server.error.include-stacktrace=on_param
server.error.include-binding-errors=on_param
- 정적 리소스
- resources/static/error/404.html (구체적인 것이 우선 순위)
- resources/static/error/4xx.html (400대 오류 디폴트 처리)
- 뷰 템플릿 (정적 리소스보다 우선 순위가 높다.)
- resources/templates/error/