[SpringBoot] 에러 전파와 /error 호출 흐름

 

 

 

 

스프링 부트 애플리케이션에서 에러가 발생했을 때, 이를 처리하기 위해 에러가 계층적으로 전파됩니다. 만약 에러가 어느 단계에서도 처리되지 않으면 최종적으로 /error 엔드포인트가 호출됩니다. 이번 글에서는 에러 전파의 흐름과 /error가 호출되는 과정을 정리해보겠습니다.

---

🌱 에러 전파 순서

1. 예외 발생
   • 에러는 컨트롤러, 서비스, 리포지토리, 필터, 인터셉터 등 다양한 위치에서 발생할 수 있습니다.
   • 예외가 발생하면 가장 가까운 예외 핸들러에서 이를 처리하려고 시도합니다.
2. Handler Method에서 핸들링 여부 확인
   • 해당 컨트롤러 메서드에 @ExceptionHandler가 정의되어 있으면 이를 실행하여 에러를 처리합니다.
   • 핸들링되지 않은 경우, 전역 예외 핸들러를 확인합니다.
3. ControllerAdvice 확인
   • @ControllerAdvice로 전역 예외 처리기가 정의되어 있다면, 해당 핸들러에서 예외를 처리합니다.
   • 이 단계에서도 처리되지 않은 경우, 예외는 DispatcherServlet으로 전달됩니다.
4. DispatcherServlet으로 전달
   • 스프링의 중심 역할을 하는 DispatcherServlet이 에러를 확인합니다.
   • 여기서도 처리되지 않은 예외는 서블릿 컨테이너로 전파됩니다.
5. Servlet Container로 전파
   • 서블릿 컨테이너(Tomcat, Jetty 등)는 등록된 에러 페이지 설정에 따라 에러를 처리하려고 합니다.
   • 스프링 부트의 기본 설정에서는 /error URL로 요청을 위임합니다.
6. BasicErrorController에서 최종 처리
   • /error 엔드포인트는 스프링 부트의 BasicErrorController가 처리합니다.
   • 요청 유형에 따라 HTML 뷰(error.html) 또는 JSON 에러 응답을 반환합니다.

---

🌱 에러 전파 순서도

[Exception 발생]
       ↓
[Handler Method]
   (ExceptionHandler 확인)
       ↓
[ControllerAdvice]
   (글로벌 ExceptionHandler 확인)
       ↓
[DispatcherServlet]
   (핸들링 실패 시 예외 전파)
       ↓
[Servlet Container]
   (에러 페이지 매핑 또는 /error 호출)
       ↓
[BasicErrorController]
   (기본 에러 처리)

 

 

 

---

🌱 /error 호출 이유와 처리 방식

• /error는 스프링 부트의 기본 에러 처리 엔드포인트입니다.
• 기본적으로 BasicErrorController에서 제공되며, 애플리케이션에서 예외가 처리되지 않을 경우 호출됩니다.
• 처리 방식
  • HTML 요청: error.html 렌더링
  • JSON 요청: JSON 형식으로 에러 응답 반환

---

[정리]

1. 에러 전파는 컨트롤러 → DispatcherServlet → 서블릿 컨테이너 → /error 순으로 진행됩니다.
2. 각 계층에서 @ExceptionHandler나 @ControllerAdvice를 통해 예외를 처리할 수 있습니다.
3. 핸들링되지 않은 예외는 최종적으로 /error로 위임되어 BasicErrorController가 처리합니다.
4. 에러를 효과적으로 관리하려면 전역 예외 핸들러나 커스터마이징된 /error 처리 로직을 구현하는 것이 좋습니다.

스프링 부트의 기본 에러 처리 메커니즘을 이해하면, 애플리케이션의 안정성과 사용자 경험을 크게 향상시킬 수 있습니다.

 

 

 

 

References.

1. ChatGPT