스프링 MVC 2 - 정리(예외 처리와 오류 페이지)

정리(예외 처리와 오류 페이지)

• 프로젝트 생성
• 서블릿 예외 처리 - 시작
  • Exception(예외)
  • response.sendError(Http 상태 코드, 오류 메시지)
  • 톰캣이 기본으로 오류 화면을 제공함. 그러나 오류 화면이 너무 별로임.
• 서블릿 예외 처리 - 오류 화면 제공
  • 스프링 부트는 WebserverFactoryCustomizer를 가지고  원하는 오류페이지를 등록 할 수 잇었다.
  • response.sendError(404) : errorPage404 호출
  • response.sendError(500) : errorPage500 호출
  • RuntimeException 또는 그 자식 타입의 예외 : errorPageEx 호출
• 서블릿 예외 처리 - 오류 페이지 작동 원리
  • 예외 발생 흐름
    • WAS(여기까지 전파) ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러(예외발생)
  • sendError 흐름
    • WAS(sendError 호출 기록 확인) ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러(response.sendError())
  • 예외 발생화 오류 페이지 요청 흐름
    • 1. WAS(여기까지 전파) ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러(예외발생)
    • 2. WAS '/error-page/500' 다시 요청 → 필터 → 서블릿 → 인터셉터 → 컨트롤러(/error-page/500) → View
• 서블릿 예외 처리 - 필터
  • 컨트롤러에서 예외가 터져서 예외가 WAS까지 올라가면, WAS가 오류페이지를 다시 요청을 하는데, 
    여기서 발생하는 문제는, 필터나 인터셉트가 중복호출 될 수 있다는 문제이다.
  • 그래서 DispatcherType이라는 것이 있었다. 
    • REQEUST : 클라이언트 요청
    • ERROR : 오류 요청
    • ex) 필터를 등록할 때, .setDispatcherTypes(DispatcherType.REQUEST); 이렇게 등록하면 REQUEST에서만 필터가 동작하도록 할 수 있었다.
    • 참고로, default가 REQUEST이다.
• 서블릿 예외 처리 - 인터셉터
  • 인터셉터는 스프링기술이기 때문에 DispatcherType가지고 할 수는 없다.
  • .excludePathPatterns에서 오류페이지 경로를 빼주는 것으로 인터셉터를 오류페이지 호출 시에는 동작하지 않도록 할 수 있다.
• 스프링 부트 - 오류 페이지1
  • 스프링 부트는 ErrorPage를 자동으로 등록한다. 이때, '/error'라는 경로로 기본 오류 페이지를 설정한다.
  • BasicErrorController라는 스프링 컨트롤러를 자동으로 등록한다. - ErrorPage에서 등록한 '/error'를 매핑해서 처리하는 컨트롤러다.
  • BasicErrorController의 처리 순서
    • 1. 뷰 템플릿 (500.html → 5xx.html) 내부 우선순위는 구체적인 것 에서 추상적인 것으로
    • 2. 정적 리소스
    • 3. 적용 대상이 없을 때 뷰 이름('error')
• 스프링 부트 - 오류 페이지2
  • BasicErrorController는 모델에 오류 정보를 담아서 반환해준다.
  • application.properties에 옵션을 적용해서  오류 정보들을 model에 포함할지 여부를 선택할 수 있다.
    (단, 고객에게 보여주지 말고 내부에서 사용할 것을 권장)
  • 에러 공통 처리 컨트롤러의 기능을 변경하고 싶으면, 'ErrorController'인터페이스를 상속받아서 구현하거나,
    BasicErrorController를 상속받아서 기능을 추가하면 된다.
• 정리