작성
·
45
0
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.
1. 강의 내용과 관련된 질문을 남겨주세요.
2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.
(자주 하는 질문 링크: https://bit.ly/3fX6ygx)
3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.
(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.
=========================================
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예/아니오)
예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)
예
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)
예
[질문 내용]
섹션 9에서 예외 발생에 대해 설명주실때 다음과 같이
WAS - > 필터 -> 서블릿 - > 인터셉터 - >컨트롤러(예외발생)
위와 같은 순서로 발생시 이를 다시 was 까지 전파하고
WAS 에서는 다시 아래와 같은 순서로 요청 한다고 주셨습니다.
WAS /error-page/500
다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/error-page/
500) -> View
본론으로 넘어와서 섹션 10에서
ExceptionResolver 적용 전 그림에서 는 was 까지 예외가 전파 되지 않고 afterCompletion 만 호출하고 종료되는 걸로 이해했습니다.
ExceptionResolver 적용 후 그림에서는 예외가 발생할 경우 afterCompletion 호출 전 ExceptionResolver 를 호출 하고 내부에서 예외를 처리한 이후 그다음 afterCompletion 을 호출하고 랜더링 이후 마지막으로 was 로 응답을 주는게 맞을까요?
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 정동희님.
스프링 MVC에서 예외 처리의 흐름은 복잡할 수 있지만, 이해를 돕기 위해 간단히 설명해 보겠습니다.
기본 프로세스:
WAS의 오류 처리:
ExceptionResolver 적용 전:
ExceptionResolver 적용 후:
이 주제와 관련된 유사한 질문과 답변들이 있을 수 있습니다. 직접 관련된 예시는 없지만, 예외 처리 흐름에 대한 이해를 돕기 위해 다음의 답변들이 도움이 될 수 있습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
안녕하세요. 정동희님
앞서 질문주신 내용은 서블릿 컨테이너(WAS)까지 예외가 올라가는데요. 그리고 /error-page/500을 요청했습니다.
ExceptionResolver를 통해 예외를 잘 처리하는 경우에는 서블릿 컨테이너(WAS)까지 예외가 올라가지 않는다는 뜻입니다.
감사합니다.
결론 적으로는 ExceptionResolver 적용 전에는 was 까지 에러가 전부 전파되고 BasicController 를 통해서 에러를 맡겨 처리하지만
ExceptionResolver 를 적용하면 기존 was 까지 올라가지 않고 중간에 Interceptor 처럼 에러를 가로채고 이를 내부 사용자의 입맛에 맡게 처리 한뒤 was 에는 에러 없이 정상적으로 처리 한것 처럼 비어있는 ModelAndView 를 반환하는 것으로 이해 했습니다.
다만 마지막에 "서블릿 컨테이너까지 예외가 올라가면 복잡하고 지저분하게 추가 프로세스가 실행된다." 라는 부분을 잘 이해하지 못했습니다.