스프링 MVC에서의 에러 페이지 리다이렉션 이해하기

스프링 MVC에서의 예외 처리와 에러 페이지 리다이렉션에 대해 알아보겠습니다. 특히 @ExceptionHandler와 web.xml 설정의 관계, 그리고 우선순위에 대해 자세히 살펴보겠습니다.

1. 예외 처리 방식의 우선순위

스프링 MVC에서 예외 처리와 에러 페이지 리다이렉션의 우선순위는 다음과 같습니다:

1) 스프링 MVC의 @ExceptionHandler
2) 스프링 MVC의 @ControllerAdvice
3) web.xml의 <error-page> 설정
4) 서블릿 컨테이너의 기본 에러 페이지

2. @ExceptionHandler와 web.xml 설정의 충돌

다음과 같은 코드가 있다고 가정해봅시다:

@Controller
public class ExceptionController {
    @ExceptionHandler(Exception.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    public String catcher(Exception ex, Model m) {
        return "error";
    }
}

 

그리고 web.xml에 다음과 같은 설정이 있습니다:

<error-page>
    <error-code>500</error-code>
    <location>/error500.jsp</location>
</error-page>

 

이 경우, 예외가 발생하면 @ExceptionHandler가 먼저 동작하여 "error"라는 뷰를 반환합니다. 따라서 web.xml에 정의된 error500.jsp로의 리다이렉션은 무시됩니다.

3. 해결 방법

web.xml 설정대로 error500.jsp로 리다이렉션하려면 다음과 같은 방법을 사용할 수 있습니다:

 

1) catcher 메서드에서 직접 "error500"을 반환:

   return "error500";

 

2) 예외를 다시 던져 서블릿 컨테이너가 처리하도록 함:

   @ExceptionHandler(Exception.class)
   @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
   public void catcher(Exception ex) throws Exception {
       throw ex;
   }

4. web.xml 설정의 장단점

web.xml에서 에러 페이지를 설정하는 방식은 다음과 같은 특징이 있습니다:

장점:

• 서블릿 컨테이너 수준에서 작동하여 애플리케이션 전체에 대한 기본 에러 처리 제공
• 설정이 간단하고 직관적

단점:

• 세밀한 예외 처리가 어려움
• 동적인 에러 처리나 복잡한 로직 적용이 제한적

5. 결론

현대적인 스프링 애플리케이션에서는 @ExceptionHandler와 @ControllerAdvice를 사용한 예외 처리를 주로 사용하고, web.xml 설정은 보조적인 역할로 사용하는 것이 좋습니다. 프로젝트의 요구사항과 복잡성에 따라 적절한 방식을 선택하는 것이 중요합니다.

예외 처리 메커니즘의 우선순위를 이해하고 각 방식의 장단점을 파악하면, 더 효과적인 에러 처리 전략을 수립할 수 있습니다.