61. 서블릿 예외처리

서블릿의 예외처리 지원방식

Exception : 우리가 아는 그 예외임.

response.sedError(HTTP코드, 메시지)

 

 

만약 컨트롤러에서 예외가 터지면

WAS <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러

이렇게 역방향으로 어딘가 예외처리를 하는 곳이 있는지 거슬러 올라간다.

 

만약 WAS까지 에러가 올라간다면 어떻게 될까?

(우선 실험을 위해 application.properties에 server.error.whitelabel.enabled=false 로 해놔서 스프링이 제공하는 기본 에러페이지는 꺼둔다.)

 

 

@Slf4j
@Controller
public class ServletExController {
    @GetMapping("/error-ex")
    public void errorEx(){
        throw new RuntimeException("예외발생!!");
    }
}

 

이렇게 하면 500 에러가 뜬다.

500에러는 서버 에러로, 현재 서버가 해결할 수 없는 에러 라고 한다.

Exception이 터지면 그건 무조건 500에러로 처리된다.

 

그리고 스프링 기본 오류페이지를 꺼놔서, 톰캣이 제공하는 기본 에러 페이지가 나온다.

 

 

다음은 response.sendError()이다

@Slf4j
@Controller
public class ServletExController {
    @GetMapping("/error-404")
    public void error404(HttpServletResponse response) throws IOException {
        response.sendError(404, "404 오류!!");
    }

    @GetMapping("/error-500")
    public void error500(HttpServletResponse response) throws IOException {
        response.sendError(500);
    }
}

예외가 올라가는 순서는

WAS <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러

인데, 이 sendError()는 호출했다고 당장 예외가 터지는 것이 아니고, WAS에게 예외가 있다고 알려주는 것이다.

WAS가 response.sendError()를 한번 까 봐서 확인하는 것이다.

 

이것의 장점은 에러코드를 지정할 수 있고, 메시지를 넣을 수 있다는 것이다.

 

나오는 페이지는 똑같다.