한 걸음 더, 개발자

스프링 부트가 기본으로 제공하는 ExceptionResolverHandlerExceptionResolverComposite에 등록된 순서ExceptionHandlerExceptionResolverResponseStatusExceptionResolverDefaultHandlerExceptionResolver ExceptionHandlerExceptionResolver@ExceptionHandler를 처리, API 예외 처리는 대부분 이 기능으로 해결 ResponseStatusExceptionResolverHTTP 상태 코드를 지정해줌 DefaulHandlerExceptionResolver스프링 내부 기본 예외를 처리 ResponseStatusExceptionResolverResponseStatusExcep..

목표예외가 발생해서 서블리을 넘어 WAS까지 예외가 전달되면 HTTP 상태코드가 500으로 처리됨. 발생하는 예외에 따라서 400, 404 등등 다른 상태코드로 처리할 것오류 메이시, 형식 등을 API마다 다르게 처리하고 싶음 상태 코드 변환예를 들어서 IllegalArgumentException을 처리하지 못해서 컨트롤러 밖으로 넘어가는 일이 발생하면 HTTP 상태코드를 400으로 처리하고 싶음. ApiExceptionController 수정@GetMapping("/api/members/{id}")public MemberDto getMember(@PathVariable("id") String id){ if(id.equals("ex")){ throw new RuntimeException("잘못..

API 예외 처리도 스프링 부트가 제공하는 기본 오류 방식을 사용할 수 있음스프링 부트가 제공하는 BasicErrorController 코드를 보면 BasicErrorController@RequestMapping( produces = {"text/html"})public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) { HttpStatus status = this.getStatus(request); Map model = Collections.unmodifiableMap(this.getErrorAttributes(request, this.getErrorAttributeOptions(reques..

목표API 예외 처리는 어떻게 해야할까? HTML 페이지의 경우 4xx, 5xx와 같은 오류 페이지만 있으면 대부분의 문제를 해결할 수 있음그런데 API의 경우에는 생각할 내용이 더 많음. 오류 페이지는 단순히 고객에게 오류 화면을 보여주고 끝이지만, API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려줘야 함 지금부터 API의 경우 어떻게 예외 처리를 하면 좋은지에 대해서 알아볼 것API도 오류 페이지에서 설명했던 것 처럼 처음으로 돌아가서 서블릿 오류 페이지 방식을 사용해볼 것 WebServerCustomizer@Componentpublic class WebServerCustomizer implements WebServerFactoryCustomizer { @Ov..

오류 페이지 [1]예외 처리 페이지를 만들기 위해서 복잡한 진행한 과정WebServerCustomizer 만듦예외 종류에 따라서 ErrorPage 추가예외 처리용 컨트롤러 ErrorPageController 만듦스프링 부트는 이런 과정을 모두 기본으로 제공ErrorPage를 자동으로 등록함. 이때 /error라는 경로로 기본 오류 페이지를 설정new ErrorPage("/error"), 상태코드와 예외를 설정하지 않으면 기본 오류 페이지로 사용됨서블릿 밖으로 예외가 발생하거나, response.sendError(...)가 호출되면 모든 오류는 /error를 호출하게 됨BasicErrorController라는 스프링 컨트롤러를 자동으로 등록ErrorPage에서 등록한 /error를 매핑해서 처리하는 컨트롤..