8. 예외 처리와 오류 페이지

ys·2024년 1월 12일
Springspring mvc2

Spring-mvc2

목록 보기
8/10

김영한 강사님의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술을 듣고 정리한 내용입니다. 자세한 내용은 강의를 참고해주세요

  • 이번강의에서는 어떻게 예외 처리가 되는지 알아보기 위해, 스프링이 아닌 순수 서블릿 컨테이너에는 예외를 어떻게 처리하는지를 알아보고
  • 그 후에 스프링을 이용해서 손쉽게 예외를 처리하는 방법을 알아볼 것이다
  • 서블릿의 예외처리 방법을 잘 알아야지, 스프링 또한 잘 이해할 수 있고, 더 나아가 오류가 났을 때 잘 대처할 수 있다.

서블릿 예외 처리

  • 서블릿은 두가지 방법으로 예외 처리를 지원한다
  1. Exception
  2. response.sendError(Http 상태 코드, 오류 메시지)

Exception

  • 자바에서는 main 쓰레드에서 예외가 나서, 예외를 못잡아 main()밖으로 던져지면, 예외 정보를 남기고 쓰레드는 종료된다
  • 웹 어플리케이션은 어떨까?
  • 웹 어플리케이션에서는 여러 쓰레드가 할당되고 서블릿 컨테이너에서 실행되는데..
  • 어플리케션의 예외를 try, catch문으로 잡지 못하고
  • 서블릿 밖가지 예외가 전달하면 어떻게 동작할까
  • WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)
  • 결국 톰캣 같은 WAS까지 예외가 전달된다
  • 스프링이 기본으로 제공하는 예외 페이지를 끄고
server.error.whitelabel.enabled=false
  • 예외를 만들어서 컨트롤러에서 실행을 해본다면,
  • 예외가 WAS까지 와서 tomcat이 기본적으로 제공하는 오류 화면인
    HTTP Status 500 – Internal Server Error를 볼 수 있다

response.sendError

  • 오류가 발생했을 때 HttpServletResponse 가 제공하는 sendError 라는 메서드를 사용해도 된다.
  • 이것을 호출한다고 당장 예외가 발생하는 것은 아니지만, 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다.
  • 이 메서드를 사용하면 HTTP 상태 코드와 오류 메시지도 추가할 수 있다.
  • response.sendError(HTTP 상태 코드)
  • response.sendError(HTTP 상태 코드, 오류 메시지)
  • WAS(sendError 호출 기록 확인) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(response.sendError())
  1. response.sendError() 를 호출하면 response 내부에는 오류가 발생했다는 상태를 저장해둔다.
  2. 그리고 서블릿 컨테이너는 고객에게 응답 전에 response 에 sendError() 가 호출되었는지 확인한다.
  3. 그리고 호출되었다면 설정한 오류 코드에 맞추어 기본 오류 페이지를 보여준다

이렇게 서블릿 컨테이너가 제공하는 기본 예외 처리 화면은 사용자가 보기 불편하다... 서버가 문제 있나?라고 느낄 수 있다
이제 의미 있게 요류 화면을 제공해보자

서블릿 예외 처리 - 오류 화면 제공

서블릿 오류 페이지 등록

@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);
    }
}
  • WebServerFactoryCustomizer<ConfigurableWebServerFactory>를 구현한 클래스를 만든다
  • customize : 메서드를 오버라이드해서 등록한다
  • 상태 오류 코드를 ErrorPage 객체를 생성해서 만들어준다
  • 그리고 factory에 addErrorPages를 이용해 만든 오류 객체를 추가해준다
  • 이 방법은 Servlet에서 오류를 등록하는 방법이다! -> 서블릿을 이용한다면 따라하자 ㅎㅎ

컨트롤러

  • 이제 실제 에러가 났을때, WAS가 에러페이지를 보여주는 화면을 보여주는 컨트롤러를 만들자

오류 페이지 작동 원리


1. 먼저 에러페이지로 이동을 한다...!
2. 컨트롤러부터 error가 WAS 까지 타고간다.
3. WAS는 WebServerCustomizer에 등록된 오류를 확인한다
4. 등록된 오류타입에 등록된 url로 WAS가 다시 요청을한다!(오류가 났기 때문에)
5. 오류 화면을 보여주기 위해 새로운 컨트롤러로 이동을 한다
6. 컨트롤러 로직에 따라 오류 페이지를 렌더링 하는 view로 이동한다

즉, 처음에 오류가 발생하는 컨트롤러와, WAS가 오류화면을 보여주기 위한 컨트롤러 2개가 존재하는 것이다!!!

  • WAS는 오류 페이지를 단순히 다시 요청만 하는 것이 아니라, 오류 정보를 request 의 attribute 에 추가해서 넘겨준다.
  • 필요하면 오류 페이지에서 이렇게 전달된 오류 정보를 사용할 수 있다
  • 이때, 중요한 점은 웹 브라우저(클라이언트)는 서버 내부에서, 이렇게 요청이 2번 일어나는지 전혀 모른다는 것이다
  • 오직 서버 내부에서 오류 페이지를 찾기위해 호출을 하는 것이다
  • 그런데 위의 사진에서 보듯이, 필터랑 인터셉타가 두번 씩 호출되게 된다
  • 로그인 같은 경우라면 -> 굳이 2번 비 효율적으로 확인할 필요가 있을까?
  • 그리고 2번 확인하면 안되는 경우라면???
  • 그렇기에 클라이언트로부터 발생한 정상요청인지 아니면, WAS서버에서 요류로 인한 내부요청인지 구분을 해야 한다!!!
  • 서블릿은 이를 해결하기 위해 Dispatcher Type이라는 정보를 추가 제공한다

서블릿 예외 처리 - 필터


Dispatcher Type이라고 다음과 같이 제공을 한다

  • REQUEST : 클라이언트 요청
  • ERROR : 오류 요청
  • FORWARD : MVC에서 배웠던 서블릿에서 다른 서블릿이나 JSP를 호출할 때
    • RequestDispatcher.forward(request, response);
  • INCLUDE : 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때
    • RequestDispatcher.include(request, response);
  • ASYNC : 서블릿 비동기 호출

어떻게 작동하는지 보기 위해서, 저번시간에 사용했던 LogFilter파일을 그대로 가져온 후에,,,

  • @Configuration , @Bean을 이용해 설정정보를 저장하고
  • FilterRegistrationBean<Filter> 에다가 LogFilter을 등록한다
  • setDispatcherTypes을 이용해 DispatcherType.REQUEST,
    DispatcherType.ERROR을 넣어서
  • Error와 Request 두경우만 사용하는 필터를 만든다!!!

  • 로그를 찍어보니 먼저 처음 요청할때 [REQUEST]로 클라이언트가 요청을 하였고
  • WAS에서 오류페이지를 위해 다시 요청을 보낼 때는 [ERROR]로 뜨는 것을 볼 수 있다
  • 그런데, filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST,DispatcherType.ERROR);이 기본 타입이기 때문에
  • 굳이, 오류 페이지 경로를 필터로 적용할 것이 아니라면, 기본값을 그대로 사용하면 된다.

서블릿 예외 처리 - 인터셉터

  • 필터와 마찬가지로, 인터셉터 또한 오류로 인한 요청에 대해서, 중복 호출을 제거해보자

    마찬가지로 저번시간에 했었던 LogInterceptor 파일을 가져온다

  • 앞서 필터의 경우에는 필터를 등록할 때 어떤 DispatcherType 인 경우에 필터를 적용할 지 선택할 수 있었다

  • 그런데 인터셉터는 서블릿에서 제공하는게 아니라 스프링에서 제공하는 기능이다

  • DispatcherType이 없다...

  • 따라서, WAS가 오류페이지를 제공하기 위해 이동하는 컨트롤러 url을 excludePathPatterns통해서 제거해주면 된다

  • 여기서는 /error-page/**이므로

@Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns("/css/**","*.ico","/error","/error-page/**");
  • 이렇게 해서 @Configuration에 담아주면 된다

전체 흐름 정리

  1. WAS(/error-ex, dispatchType=REQUEST) -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러
  2. WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)
  3. WAS 오류 페이지 확인
  4. WAS(/error-page/500, dispatchType=ERROR) -> 필터(x) -> 서블릿 -> 인터셉터(x) -> 컨트롤러(/error-page/500) -> View

지금까지 오류가 나면 서블릿에서 어떻게 처리되는지 알아보았다, 이제부터 Spring에서 어떻게 편리하게 이용할 수 있는지 알아보자

스프링 부트- 오류페이지

  • 지금까지 우리는 서블릿을 이용하면서
  1. WebServerCustomizer을 이용해 예외처리 페이지를 만들었고
  2. 예외 종류에 따라서 ErrorPage를 추가하고, 각각의 예외 종류 마다, 예외 처리용 컨트롤러 ErrorPageController를 만들었다

스프링 부트가 제공!!!

  1. Errorpage를 자동으로 등록해준다!!!
  • /error라는 경로로 기본 오류 페이지를 설정한다
  • new ErrorPage("/error")의 상태코드와 예외를 설정하지 않으면, 기본 오류 페이즈를 등록한다
  1. BasicErrorController 라는 스프링 컨트롤러를 자동으로 등록한다
  • 이 컨트롤러는 오류 페이지를 보여주는 컨트롤러이다
  • ErrorPage에서 등록한 /error를 매핑해서 처리하는 컨트롤러이다

이제 오류가 발생했을 때 오류 페이지로 /error 를 기본 요청한다. 스프링 부트가 자동 등록한BasicErrorController 는 이 경로를 기본으로 받는다

개발자는 오류 페이지만 등록

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


  • 위사진처럼 등록해주면 끝이다.. 컨트롤러며, 오류를 추가할 필요도 없다...

BasicErrorController가 제공하는 기본 정보들

  • BasicErrorController 컨트롤러는 다음 정보를 model에 담아서 뷰에 전달한다.
  • 뷰 템플릿은 이 값을 활용해서 출력할 수 있다.

  • 이렇게 thymeleaf를 이용해 화면에서, 출력할 수 있다
  • 오류 관련 내부 정보들을 고객에게 노출하는 것은 좋지 않다.
  • 고객이 해당 정보를 읽어도 혼란만 더해지고, 보안상 문제가 될 수도 있다.

application.properties

  • server.error.include-exception=false : exception 포함 여부( true , false )
  • server.error.include-message=never : message 포함 여부
  • server.error.include-stacktrace=never : trace 포함 여부
  • server.error.include-binding-errors=never : errors 포함 여부

  • on_param 으로 설정하고 다음과 같이 HTTP 요청시 파라미터를 전달하면 해당 정보들이 model 에 담겨서 뷰 템플릿에서 출력된다. message=&errors=&trace=

실무에서는 이것들을 노출하면 안된다! 사용자에게는 이쁜 오류 화면과 고객이 이해할 수 있는 간단한 오류 메시지를 보여주고 오류는 서버에 로그로 남겨서 로그로 확인해야 한다.

스프링 부트 오류 관련 옵션

  • server.error.whitelabel.enabled=true : 오류 처리 화면을 못 찾을 시, 스프링 whitelabel 오류 페이지 적용
  • server.error.path=/error : 오류 페이지 경로, 스프링이 자동 등록하는 서블릿 글로벌 오류 페이지 경로와 BasicErrorController 오류 컨트롤러 경로에 함께 사용된다.
  • ErrorController 인터페이스를 상속 받아서 구현하거나
    BasicErrorController 상속 받아서 기능을 추가하면 공통 처리 컨트롤러의 기능을 변경할 수 있다
profile
ys
개발 공부,정리
이전 포스트

7. 로그인 처리2 - 필터, 인터셉터

다음 포스트

9. API 예외 처리

0개의 댓글