[TIL] #8. 예외 처리와 오류 페이지
프로젝트 생성
🔗 코드 확인하기
실행 결과
서블릿 예외 처리 - 시작
스프링이 아닌 순수 서블릿 컨테이너가 예외를 처리하는 방법에 대해 알아보자!
📌 서블릿의 예외 처리 방법
Exception
(예외)response.sendError
(HTTP 상태 코드, 오류 메시지)
✔ Exception
1. 자바 메인 메서드 직접 실행
- 자바의 메인 메서드를 직접 실행할 경우
main
이라는 이름의 쓰레드가 실행된다. - 실행 도중 예외를 잡지 못하고
main()
메서드를 넘어서 예외가 던져지면,
예외 정보를 남기고 해당 쓰레드는 종료된다.
2. 웹 애플리케이션
- 웹 애플리케이션은 사용자 요청 별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다.
- 애플리케이션에서 예외가 발생했을 때,
try
~catch
로 예외를 잡아서 처리하면 문제 ❌- 만약 예외를 잡지 못하면, 결국 톰캣 같은 WAS까지 예외가 전달된다!
WAS (여기까지 전달!) ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러 (예외 발생)
WAS까지 예외가 전달됐을 때 어떤 일이 생기는지 알아보자!🤔
📌 주의! 스프링 부트가 제공하는 기본 예외 페이지를 꺼두자!
application.properties
에 코드를 추가해주자.
server.error.whitelabel.enabled=false
ServletExController
@Slf4j
@Controller
public class ServletExController {
@GetMapping("/error-ex")
public void errorEx() {
throw new RuntimeException("예외 발생!");
}
}
실행 결과
localhost:8080/error-ex
에 접속하면 500
오류 화면이 뜬다.
Exception
의 경우 서버 내부에서 처리할 수 없는 오류가 발생한 것으로 생각해서 HTTP 상태 코드 500
을 반환한다!
localhost:8080
처럼 아무 페이지나 접속해보면 (톰캣이 기본적으로 제공하는) 404
오류 화면이 뜬다.
✔ response.sendError(HTTP 상태 코드, 오류 메시지)
HttpServletResponse
가 제공하는 sendError
라는 메서드를 통해
- 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있으며,
- HTTP 상태 코드와 오류 메시지도 추가할 수 있다!
response.sendError(HTTP 상태 코드)
response.sendError(HTTP 상태 코드, 오류 메시지)
ServletExController
에 코드 추가
@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);
}
📌
sendError
흐름WAS (
sendError
호출 기록 확인) ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러(response.sendError())
response.sendError()
를 호출하면response
내부에 오류가 발생했다는 상태를 저장해둔다.- 서블릿 컨테이너는 고객에게 응답 전에
response
에sendError()
가 호출되었는지 확인한다.- 호출되었다면 설정한 오류 코드에 맞추어 기본 오류 페이지를 보여준다.
실행 결과
서블릿 예외 처리 - 오류 화면 제공
서블릿 컨테이너가 제공하는 기본 예외 처리 화면은
HTTP Status 404 – Bad Request
HTTP Status 500 – Internal Server Error
처럼 사용자가 의미를 파악하기 너무 어려우므로 친절한 오류 화면으로 바꿔보자!
✔ 서블릿 오류 페이지 등록
@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
@Override
public void customize(ConfigurableWebServerFactory factory) {
//HTTP 상태코드
ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
//Exception 발생
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";
}
@RequestMapping("/error-page/500")
public String errorPage500(HttpServletRequest request, HttpServletResponse response) {
log.info("errorPage 500");
return "error-page/500";
}
}
실행 결과
-
Exception
-
404
에러
-
500
에러
서블릿 예외 처리 - 오류 페이지 작동 원리
서블릿은
Exception
이 발생해서 서블릿 밖으로 전달되거나response.sendError()
가 호출되었을 때
설정된 오류 페이지를 찾는다.
✔ 오류 페이지 요청 흐름
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
이라는 추가 정보를 제공한다.
DispatcherType
서블릿 스펙은 실제 고객이 요청한 것인지, 서버가 내부에서 오류 페이지를 요청하는 것인지
DispatcherType
으로 구분할 수 있는 방법을 제공한다.
REQUEST
: 클라이언트 요청ERROR
: 오류 요청FORWARD
: 서블릿에서 다른 서블릿이나 JSP를 호출할 때RequestDispatcher.forward(request, response);
INCLUDE
: 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때RequestDispatcher.include(request, response);
ASYNC
: 서블릿 비동기 호출
필터와 DispatcherType
filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);
- 이렇게
REQUEST
,ERROR
두 가지를 모두 넣으면
클라이언트 요청은 물론이고, 오류 페이지 요청에서도 필터가 호출된다. - 아무것도 넣지 않으면 기본 값이
DispatcherType.REQUEST
이다.
→ 즉, 클라이언트의 요청이 있는 경우에만 필터가 적용된다. - 특별히 오류 페이지 경로도 필터를 적용할 것이 아니면 기본값 그대로 사용!
서블릿 예외 처리 - 인터셉터
- 필터는
DispatcherType
을 이용하여 필터 적용 여부를 선택할 수 있었다. - 인터셉터는 서블릿이 제공하는 기능이 아니라 스프링이 제공하는 기능이라서,
DispatcherType
과 무관하게 항상 호출된다.excludePathPatterns
에 오류 페이지 경로를 등록하면, 오류 페이지 호출 시 호출되지 않는다.
✔ /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
스프링 부트 - 오류 페이지1
지금까지 예외 처리 페이지를 만들기 위해 너무 많은 과정을 거쳤다😣
WebServerCustomizer
를 만들고- 예외 종류에 따라서
ErrorPage
를 추가하고 - 예외 처리용 컨트롤러
ErrorPageController
를 만들었다!
✔ 스프링 부트는 이런 과정을 모두 기본으로 제공한다!
ErrorPage
를 자동으로 등록한다. (/error
경로로 기본 오류 페이지 설정)BasicErrorController
스프링 컨트롤러를 자동으로 등록한다.BasicErrorController
는 기본적인 로직이 모두 개발되어 있음.
→ 개발자는 오류 페이지 화면만 BasicErrorController
가 제공하는 툴과 우선순위에 따라 등록하면 된다!
✔ 뷰 선택 우선순위
- 뷰 템플릿
resources/templates/error/500.html
resources/templates/error/5xx.html
- 정적 리소스 (
static
,public
)resources/static/error/400.html
resources/static/error/404.html
resources/static/error/4xx.html
- 적용 대상이 없을 때 뷰 이름 (
error
)resources/templates/error.html
+) 404, 500처럼 구체적인 것이 5xx처럼 덜 구체적인 것보다 우선순위가 높다!
실행 결과
/error-404
/error-400
/error-500
/error-ex
스프링 부트 - 오류 페이지2
BasicErrorController
가 제공하는 기본 정보들
* timestamp: Fri Feb 05 00:00:00 KST 2021
* status: 400
* error: Bad Request
* exception: org.springframework.validation.BindException
* trace: 예외 trace
* message: Validation failed for object='data'. Error count: 1
* errors: Errors(BindingResult)
* path: 클라이언트 요청 경로 (`/hello`)
BasicErrorController
컨트롤러는 이렇게 다양한 정보를 model
에 담아서 뷰에 전달한다.
뷰 템플릿은 이 값을 활용해서 출력할 수 있다.
하지만 이렇게 오류 관련 내부 정보를 고객에게 노출하는 것은 좋지 않다!
다음의 옵션들을 이용해서 공개 여부를 설정할 수 있다.
never
: 사용하지 않음always
: 항상 사용on_param
: 파라미터가 있을 때 사용- 디버그 시 문제를 확인하기 위해서 사용할 수 있다.
on_param
도 개발 서버에서 사용할 수는 있지만, 운영 서버에서 권장하지 않는다!
사용자에게는 어떤 오류인지 잘 알아볼 수 있는 정도만 전달하자!😉
Author And Source
이 문제에 관하여([TIL] #8. 예외 처리와 오류 페이지), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@mmy789/TIL-8.-예외-처리와-오류-페이지저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)