'HandlerExceptionResolver' 태그의 글 목록

HandlerExceptionResolver에 해당되는 글 1건

2022.07.16 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 17

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 17

Spring 정리 2022. 7. 16. 22:46

인프런 강의 55일차.

- 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 1 (김영한 강사님)

- 1편에서 배운 MVC를 활용할 수 있는 기술 습득

- 타입 컨버터, 파일 업로드, 활용, 쿠키, 세션, 필터, 인터셉터, 예외 처리, 타임리프, 메시지, 국제화, 검증 등등

9.1 API 예외 처리 - 시작

- API 예외 처리는 어떻게 해야할까

- HTML 페이지의 경우 지금까지 설명했던 것 처럼 4xx, 5xx와 같은 오류 페이지만 있으면 대부분의 문제를 해결할 수 있다.

- 그런데 API의 경우에는 생각할 내용이 더 많다.

- 오류 페이지는 단순히 고객에게 오류 화면을 보여주고 끝이지만, API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려주어야 한다.

- 지금부터 API의 경우 어떻게 예외 처리를 하면 좋은지 알아보자.

- API도 오류 페이지에서 설명했던 것 처럼 처음으로 돌아가서 서블릿 오류 페이지로 방식을 사용해보자

package hello.exception;

import org.springframework.boot.web.server.ConfigurableWebServerFactory;
import org.springframework.boot.web.server.ErrorPage;
import org.springframework.boot.web.server.WebServerFactoryCustomizer;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {

    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        //Springboot에서 제공해주는 ErrorPage 클래스는 사용해 에러 정의
        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500");

        factory.addErrorPages(errorPage404, errorPage500, errorPageEx);     //에러 페이지 등록
    }
}

- hello.exception.WebServerCustomizer.java

- WebServerCustomizer 가 다시 사용되도록 하기 위해 @Component 애노테이션에 적용한 주석을 풀자

- 이제 WAS에 예외가 전달되거나, response.sendError() 가 호출되면 위에 등록한 예외 페이지 경로가 호출된다

package hello.exception.api;

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

@Slf4j
@RestController
public class ApiExceptionController {


    @GetMapping("/api/members/{id}")
    public MemberDto getMember(@PathVariable("id") String id) {
        if(id.equals("ex")) {
            throw new RuntimeException("잘못된 사용자");
        }
        return new MemberDto(id, "hello " + id);
    }


    @Data
    @AllArgsConstructor
    static class MemberDto {
        private String memberId;
        private String name;
    }
}

- hello.exception.api.ApiExceptionController.java

- 회원을 조회하는 기능을 만들고, 예외 테스트를 위해 URL에 전달된 id 의 값이 ex 이면 예외가 발생하도록 구현.

* 정상 호출 시 응답

{
    "memberId": "spring",
    "name": "hello spring"
}

- Postman으로 테스트

- HTTP Header에 Accept 가 application/json으로 날려야 JSON으로 날아간다는 것을 주의

- API를 요청했는데, 정상의 경우 API로 JSON 형식으로 데이터가 정상 반환된다.

* 예외 발생 오류 호출 시 응답

<!DOCTYPE HTML>
<html>
    <head>
    </head>
    <body>
    ...
    </body>
</html>

- 그런데 오류가 발생하면 우리가 미리 만들어둔 오류 페이지 HTML이 반환된다. 이것은 기대하는 바가 아니다.

- 클라이언트는 정상 요청이든, 오류 요청이든 JSON이 반환되기를 기대한다.

- 웹 브라우저가 아닌 이상 HTML을 직접 받아서 할 수 있는 것은 별로 없다.

- 오류 페이지 컨트롤러도 JSON 응답을 할 수 있도록 수정해야 한다.

package hello.exception.servlet;

import lombok.extern.slf4j.Slf4j;
...

@Slf4j
@Controller
public class ErrorPageController {

	...
    //Client가 보내는 헤더 타입에 대해 자세하게 정의되어 있는 메소드를 먼저 호출한다.
    //application/json인 경우 같은 error-page/500이 호출되었을 때 produces에 APPLICATION_JSON_VALLUE 가 걸린 메소드가 먼저 호출된다.
    @RequestMapping(value = "/error-page/500", produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<Map<String, Object>> errorPage500Api (HttpServletRequest request, HttpServletResponse response) {
        log.info("API errorPage 500");

        HashMap<String, Object> result = new HashMap<>();
        Exception ex = (Exception) request.getAttribute(ERROR_EXCEPTION);;

        result.put("status", request.getAttribute(ERROR_STATUS_CODE));
        result.put("message", ex.getMessage());

        Integer statusCode = (Integer) request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);

        return  new ResponseEntity<>(result, HttpStatus.valueOf(statusCode));
    }
    ...
}

- hello.exception.servlet.ErrorPageController.java

- produces = MediaType.APPLICATION_JSON_VALUE 의 뜻은 클라이언트가 요청하는 HTTP Header의 Accept 의 값이 application/json 일 때 해당 메소드가 호출된다는 것이다.

> 결국 클라어인트가 받고 싶은 미디어타입이 json이면 이 컨트롤러의 메소드가 호출된다.

- 응답 데이터를 위해서 HashMap 을 만들고 status, message 키에 값을 할당했다.

> Jackson 라이브러리는 Map 을 JSON 구조로 변환할 수 있다.

- ResponseEntity 를 사용해서 응답하기 때문에 메시지 컨버터가 동작하면서 클라이언트에 JSON이 반환된다

* APPLICATION_JSON_VALUE 추가 후 예외 발생 오류 호출 시 응답

{
    "message": "잘못된 사용자",
    "status": 500
}

- HTTP Header에 Accept 가 application/json 이 아니면, 기존 오류 응답인 HTML 응답이 출력되는 것을 확인할 수 있다

9.2 API 예외 처리 - 스프링 부트 기본 오류 처리

- API 예외 처리도 스프링 부트가 제공하는 기본 오류 방식을 사용할 수 있다.

@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) {
   HttpStatus status = getStatus(request);
   Map<String, Object> model = Collections
         .unmodifiableMap(getErrorAttributes(request, getErrorAttributeOptions(request, MediaType.TEXT_HTML)));
   response.setStatus(status.value());
   ModelAndView modelAndView = resolveErrorView(request, response, status, model);
   return (modelAndView != null) ? modelAndView : new ModelAndView("error", model);
}

@RequestMapping
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {
   HttpStatus status = getStatus(request);
   if (status == HttpStatus.NO_CONTENT) {
      return new ResponseEntity<>(status);
   }
   Map<String, Object> body = getErrorAttributes(request, getErrorAttributeOptions(request, MediaType.ALL));
   return new ResponseEntity<>(body, status);
}

- 스프링부트에서 제공하는 BasicErrorController.java

- /error 동일한 경로를 처리하는 errorHtml() , error() 두 메서드를 확인할 수 있다

- errorHtml() : produces = MediaType.TEXT_HTML_VALUE이므로 클라이언트 요청의 Accept 헤더 값이 text/html 인 경우에는 errorHtml() 을 호출해서 view를 제공한다.

- error() : 그외 경우에 호출되고 ResponseEntity 로 HTTP Body에 JSON 데이터를 반환한다.

* 스프링 부트의 예외 처리

- 스프링 부트의 기본 설정은 오류 발생시 /error 를 오류 페이지로 요청한다.

- BasicErrorController 는 이 경로를 기본으로 받는다. ( server.error.path 로 수정 가능, 기본 경로 / error )

- BasicErrorController 를 사용하도록 WebServerCustomizer 의 @Component 를 주석처리 하자

> WebServerCustomizer 은 서블릿에서 제공하는 예외처리

{
    "timestamp": "2022-07-16T00:00:00.000+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "exception": "java.lang.RuntimeException",
    "trace": "java.lang.RuntimeException: 잘못된 사용자\n\tat
    hello.exception.web.api.ApiExceptionController.getMember(ApiExceptionController.java:19...,
    "message": "잘못된 사용자",
    "path": "/api/members/ex"
}

- 스프링 부트는 BasicErrorController 가 제공하는 기본 정보들을 활용해서 오류 API를 생성해준다

* Html 페이지 vs API 오류

- BasicErrorController 를 확장하면 JSON 메시지도 변경할 수 있다. 그런데 API 오류는 조금 뒤에 설명할 @ExceptionHandler 가 제공하는 기능을 사용하는 것이 더 나은 방법이므로 지금은 BasicErrorController 를 확장해서 JSON 오류 메시지를 변경해보자.

- 스프링 부트가 제공하는 BasicErrorController 는 HTML 페이지를 제공하는 경우에는 매우 편리하다.

- 4xx, 5xx 등등 모두 잘 처리해준다. 그런데 API 오류 처리는 다른 차원의 이야기이다.

- API 마다, 각각의 컨트롤러나 예외마다 서로 다른 응답 결과를 출력해야 할 수도 있다.

> 예를 들어서 회원과 관련된 API에서 예외가 발생할 때 응답과, 상품과 관련된 API에서 발생하는 예외에 따라 그 결과가 달라질 수 있다.

- 결과적으로 매우 세밀하고 복잡하다.

- 따라서 이 방법은 HTML 화면을 처리할 때 사용하고, API는 오류 처리는 뒤에서 설명할 @ExceptionHandler 를 사용하자

9.3 API 예외 처리 - HandlerExceptionResolver 시작

- 예외가 발생해서 서블릿을 넘어 WAS까지 예외가 전달되면 HTTP 상태코드가 500으로 처리된다.

- 발생하는 예외에 따라서 400, 404 등등 다른 상태코드도 처리해보자,

- 오류 메시지, 형식등을 API마다 다르게 처리해보자.

- IllegalArgumentException 을 처리하지 못해서 컨트롤러 밖으로 넘어가는 일이 발생하면 HTTP 상태코드를 400으로 처리하고 싶다. 어떻게 해야할까?

...

@Slf4j
@RestController
public class ApiExceptionController {

    @GetMapping("/api/members/{id}")
    public MemberDto getMember(@PathVariable("id") String id) {
        if (id.equals("ex")) {
            throw new RuntimeException("잘못된 사용자");
        }
        if (id.equals("bad")) {
            throw new IllegalArgumentException("잘못된 입력 값");
        }
        return new MemberDto(id, "hello " + id);
    }
	...
}

- hello.exception.api.ApiExceptionController.java

- /api/members/bad 호출 시 IllegalArgumentException이 발생하도록 처리했다.

* /api/members/bad 호출 결과

{
    "status": 500,
    "error": "Internal Server Error",
    "exception": "java.lang.IllegalArgumentException",
    "path": "/api/members/bad"
}

- Http Status 500 에러가 발생함을 확인

* HandlerExceptionResolver

- 스프링 MVC는 컨트롤러(핸들러) 밖으로 예외가 던져진 경우 예외를 해결하고, 동작을 새로 정의할 수 있는 방법을 제공한다.

- 컨트롤러 밖으로 던져진 예외를 해결하고, 동작 방식을 변경하고 싶으면 HandlerExceptionResolver 를 사용하면 된다. 줄여서 ExceptionResolver 라 한다

* ExceptionResolver 적용 전

* ExceptionResolver 적용 후

> ExceptionResolver 를 적용하기 전에도 컨트롤러에서 예외가 발생하면 postHandle()가 호출되지 않았다.

> ExceptionResolver 로 예외를 해결해도 postHandle() 은 호출되지 않는다

* HandlerExceptionResolver - 인터페이스

public interface HandlerExceptionResolver {
    ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response,Object handler, Exception ex);
}

- handler : 핸들러(컨트롤러) 정보

- Exception ex : 핸들러(컨트롤러)에서 발생한 발생한 예외

* MyHandlerExceptionResolver

package hello.exception.resolver;

import lombok.extern.slf4j.Slf4j;
import org.springframework.web.servlet.HandlerExceptionResolver;
import org.springframework.web.servlet.ModelAndView;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@Slf4j
public class MyHandlerExceptionResolver implements HandlerExceptionResolver {

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {

        log.info("resolveException --- ");
        try {
            if (ex instanceof IllegalArgumentException) {
                log.info("IllegalArgumentException resolver to 400");
                response.sendError(HttpServletResponse.SC_BAD_REQUEST, ex.getMessage());
                return new ModelAndView();
            }
        } catch (IOException e) {
            log.error("resolver ex ", e);
        }
        return null;        //null로 리턴 시 전달받은 예외가 그대로 전달됨
    }
}

- hello.exception.resolver.MyHandlerExceptionResolver.java

- ExceptionResolver 가 ModelAndView 를 반환하는 이유는 try, catch를 하듯이 Exception 을 처리해서 정상 흐름 처럼 변경하는 것이 목적이다. 이름 그대로 Exception 을 Resolver(해결)하는 것이 목적이다.

- 여기서는 IllegalArgumentException 이 발생하면 response.sendError(400) 를 호출해서 HTTP 상태 코드를 400으로 지정하고, 빈 ModelAndView 를 반환한다

* 반환 값에 따른 동작 방식

- HandlerExceptionResolver 의 반환 값에 따른 DispatcherServlet 의 동작 방식은 다음과 같다.

> 빈 ModelAndView : new ModelAndView() 처럼 빈 ModelAndView 를 반환하면 뷰를 렌더링 하지 않고, 정상 흐름으로 서블릿이 리턴된다.

> 특정 ModelAndView 지정 : ModelAndView 에 View , Model 등의 정보를 지정해서 반환하면 뷰를 렌더링 한다.

> null: null 을 반환하면, 다음 ExceptionResolver 를 찾아서 실행한다. 만약 처리할 수 있는 ExceptionResolver 가 없으면 예외 처리가 안되고, 기존에 발생한 예외를 서블릿 밖으로 던진다.

* ExceptionResolver 활용

- 예외 상태 코드 변환

> 예외를 response.sendError(xxx) 호출로 변경해서 서블릿에서 상태 코드에 따른 오류를 처리하도록 위임

> 이후 WAS는 서블릿 오류 페이지를 찾아서 내부 호출, 예를 들어서 스프링 부트가 기본으로 설정한 / error 가 호출됨

- 뷰 템플릿 처리

> ModelAndView 에 값을 채워서 예외에 따른 새로운 오류 화면 뷰 렌더링 해서 고객에게 제공

- API 응답 처리

> response.getWriter().println("hello"); 처럼 HTTP 응답 바디에 직접 데이터를 넣어주는 것도 가능하다.

> 여기에 JSON 으로 응답하면 API 응답 처리를 할 수 있다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns("/css/**", "*.ico", "/error", "/error-page/**");
    }

    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
        //내가 구현한 ExceptionResolver를 ExceptionHandler에 등록한다.
        resolvers.add(new MyHandlerExceptionResolver());
    }
	...
}

- hello.exception.WebConfig.java

- configureHandlerExceptionResolvers(..) 를 사용하면 스프링이 기본으로 등록하는 ExceptionResolver 가 제거되므로 주의,

> extendHandlerExceptionResolvers 를 사용하자

* Postman으로 실행

- http://localhost:8080/api/members/ex -> HTTP 상태 코드 500 반환

- http://localhost:8080/api/members/bad -> HTTP 상태 코드 400 반환

9.4 API 예외 처리 - HandlerExceptionResolver 활용

- 예외가 발생하면 WAS까지 던져지고, WAS에서 오류 페이지 정보를 찾아서 다시 /error 를 호출하는 과정은 복잡하다.

> ExceptionResolver 를 활용하면 예외가 발생했을 때 이런 복잡한 과정 없이 깔끔하게 해결할 수 있다.

package hello.exception.exception;

public class UserException extends RuntimeException {

    public UserException() {
        super();
    }

    public UserException(String message) {
        super(message);
    }

    public UserException(String message, Throwable cause) {
        super(message, cause);
    }

    public UserException(Throwable cause) {
        super(cause);
    }

    protected UserException(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace) {
        super(message, cause, enableSuppression, writableStackTrace);
    }
}

- hello.exception.exception.UserException.java

- RuntimeException을 오버라이드한 UserException 추가

...

@Slf4j
@RestController
public class ApiExceptionController {

    @GetMapping("/api/members/{id}")
    public MemberDto getMember(@PathVariable("id") String id) {
        if (id.equals("ex")) {
            throw new RuntimeException("잘못된 사용자");
        }
        if (id.equals("bad")) {
            throw new IllegalArgumentException("잘못된 입력 값");
        }
        if (id.equals("user-ex")) {
            throw new UserException("사용자 오류");
        }
        return new MemberDto(id, "hello " + id);
    }
	...
}

- hello.exception.api.ApiExceptionController.java

- /api/members/user-ex 호출 시 UserException이 발생하도록 처리

- 이제 UserException을 처리하는 UserHandlerExceptionResolver를 만들어보자.

package hello.exception.resolver;

import com.fasterxml.jackson.databind.ObjectMapper;
import hello.exception.exception.UserException;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.servlet.HandlerExceptionResolver;
import org.springframework.web.servlet.ModelAndView;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

@Slf4j
public class UserHandlerExceptionResolver implements HandlerExceptionResolver {

    private final ObjectMapper objectMapper = new ObjectMapper();

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        try {
            if (ex instanceof UserException) {
                log.info("UserException resolver to 400");
                String acceptHeader = request.getHeader("accept");
                response.setStatus(HttpServletResponse.SC_BAD_REQUEST); //Https 상태코드 400으로 변경

                if ("application/json".equals(acceptHeader)) {
                    Map<String, Object> errorResult = new HashMap<>();
                    errorResult.put("ex", ex.getClass());
                    errorResult.put("message", ex.getMessage());

                    //errorResult를 objectMapper.writeValueAsString을 사용해 JSON 형태로 바꿔준다.
                    String result = objectMapper.writeValueAsString(errorResult);

                    response.setContentType("application/json");
                    response.setCharacterEncoding("utf-8");
                    response.getWriter().write(result);
                    return new ModelAndView();
                } else {
                    // TEXT/HTML
                    return new ModelAndView("error/500");
                }
            }
        } catch (IOException e) {
            log.error("resolver ex", e);
        }
        return null;
    }
}

- hello.exception.resolver.UserHandlerExceptionResolver.java

- HTTP 요청 해더의 ACCEPT 값이 application/json 이면 JSON으로 오류를 내려주고, 그 외 경우에는 error/500에 있는 HTML 오류 페이지를 보여준다.

@Configuration
public class WebConfig implements WebMvcConfigurer {
	...
    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
        //내가 구현한 ExceptionResolver를 ExceptionHandler에 등록한다.
        resolvers.add(new MyHandlerExceptionResolver());
        resolvers.add(new UserHandlerExceptionResolver());
    }
    ...
}

- 내가 만든 UserHandlerExceptionResolver를 핸들러에 등록

* /api/members/user-ex 호출 결과

//Accept : application/json 인 경우 JSON 으로 리턴
{
    "ex": "hello.exception.exception.UserException",
    "message": "사용자 오류"
}

//Accept : text/html 인 경우 HTML 코드 리턴
<!DOCTYPE HTML>
<html>
...
</html>

* 정리

- ExceptionResolver 를 사용하면 컨트롤러에서 예외가 발생해도 ExceptionResolver 에서 예외를 처리해버린다.

- 따라서 예외가 발생해도 서블릿 컨테이너까지 예외가 전달되지 않고, 스프링 MVC에서 예외 처리는 끝이 난다.

- 결과적으로 WAS 입장에서는 정상 처리가 된 것이다.

> 예외를 이곳에서 모두 처리할 수 있다는 것이 핵심이다

- 서블릿 컨테이너까지 예외가 올라가면 복잡하고 지저분하게 추가 프로세스가 실행된다.

- 반면에 ExceptionResolver 를 사용하면 예외처리가 상당히 깔끔해진다.

- 그런데 직접 ExceptionResolver 를 구현하려고 하니 상당히 복잡하다.

> 스프링이 제공하는 ExceptionResolver 들을 알아보자.

9.5 API 예외 처리 - 스프링이 제공하는 ExceptionResolver1

- 스프링 부트가 기본으로 제공하는 ExceptionResolver 는 다음과 같다.

* HandlerExceptionResolverComposite 에 3개가 순서대로 등록된다.

1. ExceptionHandlerExceptionResolver

- @ExceptionHandler 을 처리한다. API 예외 처리는 대부분 이 기능으로 해결한다.

2. ResponseStatusExceptionResolver

- HTTP 상태 코드를 지정해준다.

- @ResponseStatus(value = HttpStatus.NOT_FOUND)

3. DefaultHandlerExceptionResolver (우선 순위가 가장 낮다)

- 스프링 내부 기본 예외를 처리한다.

* ResponseStatusExceptionResolver

- ResponseStatusExceptionResolver 는 예외에 따라서 HTTP 상태 코드를 지정해주는 역할을 한다

> @ResponseStatus 가 달려있는 예외

> ResponseStatusException 예외

package hello.exception.exception;

import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.ResponseStatus;

@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "잘못된 요청 오류")
public class BadRequestException extends RuntimeException {
}

- hello.exception.exception.BadRequestException.java

- 예외에 @ResponseStatus 애노테이션을 적용하면 HTTP 상태 코드를 변경해준다.

- BadRequestException 예외가 컨트롤러 밖으로 넘어가면 ResponseStatusExceptionResolver 예외가 해당 애노테이션을 확인해서 오류 코드를 HttpStatus.BAD_REQUEST (400)으로 변경하고, 메시지도 담는다

- ResponseStatusExceptionResolver 코드를 확인해보면 결국 response.sendError(statusCode, resolvedReason) 를 호출하는 것을 확인할 수 있다.

> sendError(400) 를 호출했기 때문에 WAS에서 다시 오류 페이지( /error )를 내부 요청한다

@Slf4j
@RestController
public class ApiExceptionController {
	...
    
    @GetMapping("/api/response-status-ex1")
    public String responseStatusEx1() {
        throw new BadRequestException();
    }
    
    ...
}

- hello.exception.api.ApiExceptionController.java

- @ResponseStatus 를 테스트하기 위한 responseStatusEx1 메소드 추가

* /api/response-status-ex1 호출 결과

{
    "status": 400,
    "error": "Bad Request",
    "exception": "hello.exception.exception.BadRequestException",
    "message": "잘못된 요청 오류",
    "path": "/api/response-status-ex1"
}

- @ResponseStatus에 정의한 것 처럼 status 코드는 400으로, message는 "잘못된 요청 오류"로 변경되었다.

* 메시지 기능

- @ResponseStatus에 사용한 reason 을 MessageSource 에서 찾는 기능도 제공한다.

> reason = "error.bad" 으로 사용

error.bad=잘못된 요청 오류입니다. 메시지 사용

- message.properties 에 error.bad 값정의

* 메시지 기능 사용한 /api/response-status-ex1 호출 결과

{
    "status": 400,
    "error": "Bad Request",
    "exception": "hello.exception.exception.BadRequestException",
    "message": "잘못된 요청 오류",
    "path": "/api/response-status-ex1"
}

* ResponseStatusException

- @ResponseStatus 는 개발자가 직접 변경할 수 없는 예외에는 적용할 수 없다.

> 애노테이션을 직접 넣어야 하는데, 내가 코드를 수정할 수 없는 라이브러리의 예외 코드 같은 곳에는 적용할 수 없다.

- 추가로 애노테이션을 사용하기 때문에 조건에 따라 동적으로 변경하는 것도 어렵다.

- 이때는 ResponseStatusException 예외를 사용하면 된다.

@Slf4j
@RestController
public class ApiExceptionController {
	...
    
    @GetMapping("/api/response-status-ex2")
    public String responseStatusEx2() {
        throw new ResponseStatusException(HttpStatus.NOT_FOUND, "error.bad", new IllegalArgumentException());
    }
    
    ...
}

- hello.exception.api.ApiExceptionController.java

- 조건에 따라 동적으로 변동되는 에러를 처리하기 위해 ResponseStatusException을 구현한 responseStatusEx2 메소드

* /api/response-status-ex2 호출 결과

{
    "status": 404,
    "error": "Not Found",
    "exception": "org.springframework.web.server.ResponseStatusException",
    "message": "잘못된 요청 오류입니다. 메시지 사용",
    "path": "/api/response-status-ex2"
}

9.6 API 예외 처리 - 스프링이 제공하는 ExceptionResolver2

- DefaultHandlerExceptionResolver 를 살펴보자

- DefaultHandlerExceptionResolver 는 스프링 내부에서 발생하는 스프링 예외를 해결한다.

- 대표적으로 파라미터 바인딩 시점에 타입이 맞지 않으면 내부에서 TypeMismatchException 이 발생하는데, 이 경우 예외가 발생했기 때문에 그냥 두면 서블릿 컨테이너까지 오류가 올라가고, 결과적으로 500 오류가 발생한다.

- 그런데 파라미터 바인딩은 대부분 클라이언트가 HTTP 요청 정보를 잘못 호출해서 발생하는 문제이다.

- HTTP 에서는 이런 경우 HTTP 상태 코드 400을 사용하도록 되어 있다.

> DefaultHandlerExceptionResolver 는 이것을 500 오류가 아니라 HTTP 상태 코드 400 오류로 변경한다.

- 스프링 내부 오류를 어떻게 처리할지 수 많은 내용이 정의되어 있다

* 코드 확인

- DefaultHandlerExceptionResolver.handleTypeMismatch 를 보면 코드를 확인할 수 있다.

- response.sendError(HttpServletResponse.SC_BAD_REQUEST) (400)

> 결국 response.sendError() 를 통해서 문제를 해결한다.

> sendError(400) 를 호출했기 때문에 WAS에서 다시 오류 페이지( /error )를 내부 요청한다

@Slf4j
@RestController
public class ApiExceptionController {
	...
    
    @GetMapping("/api/default-handler-ex")
    public String defaultException(@RequestParam Integer data) {
    	return "ok";
    }
    
    ...
}

- hello.exception.api.ApiExceptionController.java

- Integer data 에 문자를 입력하면 내부에서 TypeMismatchException 이 발생한다.

* /api/default-handler-ex?data=hello&message= 호출 결과

{
    "status": 400,
    "error": "Bad Request",
    "exception": "org.springframework.web.method.annotation.MethodArgumentTypeMismatchException",
    "message": "Failed to convert value of type 'java.lang.String' to required type 'java.lang.Integer'; nested exception is java.lang.NumberFormatException: For input string: \"hello\"",
    "path": "/api/default-handler-ex"
}

- 실행 결과를 보면 TypeMismatchException이고 HTTP 상태 코드가 400인 것을 확인할 수 있다

* 정리

- 지금까지 HTTP 상태 코드를 변경하고, 스프링 내부 예외의 상태코드를 변경하는 기능도 알아보았다.

- 그런데 HandlerExceptionResolver 를 직접 사용하기는 복잡하다.

- API 오류 응답의 경우 response 에 직접 데이터를 넣어야 해서 매우 불편하고 번거롭다.

- ModelAndView 를 반환해야 하는 것도 API에는 잘 맞지 않는다.

- 스프링은 이 문제를 해결하기 위해 @ExceptionHandler 라는 매우 혁신적인 예외 처리 기능을 제공한다.

'Spring 정리' 카테고리의 다른 글

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 19 (0)	2022.07.20
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 18 (0)	2022.07.19
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 16 (0)	2022.07.16
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 15 (0)	2022.07.16
스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 14 (0)	2022.07.10

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

검색결과 리스트

HandlerExceptionResolver에 해당되는 글 1건

글

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 17

인프런 강의 55일차.

'Spring 정리' 카테고리의 다른 글

설정

트랙백

댓글

Mr.Walter

CATEGORY

TAG

RECENT POSTS

RECENT COMMENT

RECENT TRACKBACK

LINK

ARCHIVE

NOTICE

CALENDAR

COUNTER

티스토리툴바