[스프링 MVC 2편] 9. API 예외 처리
/category/%EC%9D%B8%ED%94%84%EB%9F%B0%20Spring%20%EA%B0%95%EC%9D%98%20%EC%A0%95%EB%A6%AC/%EC%8A%A4%ED%94%84%EB%A7%81%20MVC%202%ED%8E%B8%20-%20%EB%B0%B1%EC%97%94%EB%93%9C%20%EC%9B%B9%20%EA%B0%9C%EB%B0%9C%20%ED%99%9C%EC%9A%A9%20%EA%B8%B0%EC%88%A0

2024. 1. 25. 18:42

728x90

SMALL

📌 서블릿 오류 페이지 방식으로 처리

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

⚡ WebServerCustomizer 다시 동작

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){

        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);
    }
}

✔ ApiExceptionController - API 예외 컨트롤러

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;
    }
}

단순히 회원을 조회하는 기능
URL에 전달된 id의 값이 ex이면 예외 발생

Postman으로 테스트

HTTP Header에 Accept가 application/json인걸 꼭 확인 후 테스트

✔ 정상 호출

http://localhost:8080/api/members/spring

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

✔ 예외 발생 호출

http://localhost:8080/api/members/ex

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

API를 요청했는데, 정상의 경우 API로 JSON 형식으로 데이터가 정상 반환
오류가 발생하면 우리가 미리 만들어둔 오류 페이지 HTML이 반환
- 클라이언트는 정상 요청이든, 오류 요청이든 JSON이 반환되기를 기대
- 웹 브라우저가 아닌 이상 HTML을 직접 받아서 할 수 있는 것은 별로 없음
- 문제를 해결하려면 오류 페이지 컨트롤러도 JSON 응답을 할 수 있도록 수정해야 함

✔ ErrorPageController - API 응답 추가

    @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");

        Map<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, HttpStatusCode.valueOf(statusCode));
    }

produces = MediaType.APPLICATION_JSON_VALUE

클라이언트가 요청하는 HTTP Header의Accept 의 값이 application/json 일 때 해당 메서드가 호출된다는 것
- 결국 클라어인트가 받고 싶은 미디어 타입이 json이면 이 컨트롤러의 메서드가 호출됨
응답 데이터를 위해서 Map 을 만들고 status , message 키에 값을 할당
Jackson 라이브러리는 Map 을 JSON 구조로 변환 가능
ResponseEntity 를 사용해서 응답하기 때문에 메시지 컨버터가 동작하면서 클라이언트에 JSON이 반환됨

✔ 예외 발생 호출

http://localhost:8080/api/members/ex

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

📌 스프링 부트 기본 오류 처리

BasicErrorController 코드

@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) {}

@RequestMapping
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {}

/error 동일한 경로를 처리하는 errorHtml() , error() 두 메서드를 확인할 수 있음
- errorHtml() : produces = MediaType.TEXT_HTML_VALUE : 클라이언트 요청의 Accept 해더 값이 text/html 인 경우에는 errorHtml() 을 호출해서 view를 제공
- error() : 그외 경우에 호출되고 ResponseEntity 로 HTTP Body에 JSON 데이터 반환

✔ 스프링 부트의 예외 처리

BasicErrorController 는 이 경로를 기본으로 받음

server.error.path 로 수정 가능, 기본 경로 / error

Postman으로 실행

GET http://localhost:8080/api/members/ex

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

{
    "timestamp": "2024-01-18T15:12:43.051+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "exception": "java.lang.RuntimeException",
    "path": "/api/members/ex"
}

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

server.error.include-binding-errors=always 
server.error.include-exception=true 
server.error.include-message=always 
server.error.include-stacktrace=always

➡ 더 자세한 오류 추가

➡ 물론 오류 메시지는 이렇게 막 추가하면 보안상 위험

⚡ Html 페이지 VS API 오류

BasicErrorController 를 확장하면 JSON 메시지도 변경 가능
- API 오류는 @ExceptionHandler 가 제공하는 기능을 사용하는 것이 더 나은 방법이므로 BasicErrorController 를 확장해서 JSON 오류 메시지를 변경할 수 있다 정도로만 이해.
스프링 부트가 제공하는 BasicErrorController 는 HTML 페이지를 제공하는 경우에는 매우 편리
- 4xx, 5xx 등등 모두 잘 처리해줌
API 오류 처리는 API 마다, 각각의 컨트롤러나 예외마다 서로 다른 응답 결과를 출력해야 할 수도 있음
- ex) 회원과 관련된 API에서 예외가 발생할 때 응답과, 상품과 관련된 API에서 발생하는 예외에 따라 그 결과가 달라질 수 있음
- ➡ 결과적으로 매우 세밀하고 복잡
- HTML 화면을 처리할 때 사용하고, API 오류 처리는 @ExceptionHandler 를 사용

📌 HandlerExceptionResolver

예외가 발생해서 서블릿을 넘어 WAS까지 예외가 전달되면 HTTP 상태코드가 500으로 처리됨
발생하는 예외에 따라서 400, 404 등등 다른 상태코드로 처리하고 싶고, 오류 메시지, 형식등을 API마다 다르게 처리하고 싶을 때 사용

⚡ 상태코드 변환

ex) IllegalArgumentException 을 처리하지 못해서 컨트롤러 밖으로 넘어가는 일이 발생
➡ HTTP 상태코드를 400으로 처리하고 싶다면?

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);
    }

➡ http://localhost:8080/api/members/bad 라고 호출하면 IllegalArgumentException 이 발생

실행

{
    "timestamp": "2024-01-18T15:31:31.095+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "exception": "java.lang.IllegalArgumentException",
    "path": "/api/members/bad"
}

⚡ HandlerExceptionResolver

스프링 MVC는 컨트롤러(핸들러) 밖으로 예외가 던져진 경우 예외를 해결하고, 동작을 새로 정의할 수 있는 방법 제공
컨트롤러 밖으로 던져진 예외를 해결하고, 동작 방식을 변경하고 싶으면 HandlerExceptionResolver 를 사용하면 됨

줄여서 ExceptionResolver

✔ ExceptionResolver 적용 전

✔ ExceptionResolver 적용 후

cf) 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 jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.servlet.HandlerExceptionResolver;
import org.springframework.web.servlet.ModelAndView;

import java.io.IOException;

@Slf4j
public class MyHandlerExceptionResolver implements HandlerExceptionResolver {

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        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;
    }
}

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 응답 처리 가능

✔ WebConfig - 수정

    /**
     * 기본 설정을 유지하면서 추가
     */
    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers){
        resolvers.add(new MyHandlerExceptionResolver());
    }

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

Postman으로 실행
http://localhost:8080/api/members/ex

HTTP 상태 코드 500

http://localhost:8080/api/members/bad

HTTP 상태 코드 400

⚡ 활용

✔ 예외를 여기서 마무리

예외가 발생하면 WAS까지 예외가 던져지고, WAS에서 오류 페이지 정보를 찾아서 다시 /error 를 호출하는 과정은 생각해보면 너무 복잡함
ExceptionResolver 를 활용하면 예외가 발생했을 때 이런 복잡한 과정 없이 여기에서 문제를 깔끔하게 해결 가능

⚡ UserException

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);
    }
}

✔ ApiExceptionController - 예외 추가

package hello.exception.api;

import hello.exception.exception.UserException;
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("잘못된 사용자");
        }
        if(id.equals("bad")){
            throw new IllegalArgumentException("잘못된 입력 값");
        }
        if(id.equals("user-ex")){
            throw new UserException("사용자 오류");
        }
        return new MemberDto(id, "hello "+id);
    }

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

http://localhost:8080/api/members/user-ex

➡ UserException 이 발생

⚡ UserHandlerExceptionResolver

package hello.exception.resolver;

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

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);

                if("application/json".equals(acceptHeader)){
                    Map<String, Object> errorResult = new HashMap<>();
                    errorResult.put("ex", ex.getClass());
                    errorResult.put("message", ex.getMessage());
                    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;
    }

}

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

⚡ WebConfig에 UserHandlerExceptionResolver 추가

    /**
     * 기본 설정을 유지하면서 추가
     */
    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers){
        resolvers.add(new MyHandlerExceptionResolver());
        resolvers.add(new UserHandlerExceptionResolver());
    }

✔ ACCEPT : application/json

{
    "ex": "hello.exception.exception.UserException",
    "message": "사용자 오류"
}

✔ ACCEPT : text/html

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

⚡ 정리

ExceptionResolver 를 사용하면 컨트롤러에서 예외가 발생해도 ExceptionResolver 에서 예외를 처리해버림
예외가 발생해도 서블릿 컨테이너까지 예외가 전달되지 않고, 스프링 MVC에서 예외 처리는 끝이 남
결과적으로 WAS 입장에서는 정상 처리가 된 것
예외를 이곳에서 모두 처리할 수 있다는 것이 핵심
서블릿 컨테이너까지 예외가 올라가면 복잡하고 지저분하게 추가 프로세스가 실행됨
- 반면에 ExceptionResolver 를 사용하면 예외처리가 상당히 깔끔
- 직접 ExceptionResolver 를 구현하려고 하니 상당히 복잡함

📌 스프링이 제공하는 ExceptionResolver

스프링 부트가 기본으로 제공하는 ExceptionResolver
HandlerExceptionResolverComposite 에 다음 순서로 등록

ExceptionHandlerExceptionResolver
ResponseStatusExceptionResolver
DefaultHandlerExceptionResolver 우선순위가 가장 낮음

✔ ExceptionHandlerExceptionResolver

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

✔ ResponseStatusExceptionResolver

HTTP 상태 코드를 지정해줌
ex) @ResponseStatus(value = HttpStatus.NOT_FOUND)

✔ DefaultHandlerExceptionResolver

스프링 내부 기본 예외 처리

✔ ResponseStatusExceptionResolver

예외에 따라서 HTTP 상태 코드를 지정해주는 역할
@ResponseStatus 가 달려있는 예외
ResponseStatusException 예외

⚡ BadRequestException

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{
}

예외에 @ResponseStatus 애노테이션을 적용
- HTTP 상태 코드를 변경

BadRequestException 예외가 컨트롤러 밖으로 넘어가면 ResponseStatusExceptionResolver 예외가 해당 애노테이션을 확인해서 오류 코드를 HttpStatus.BAD_REQUEST (400)으로 변경하고, 메시지도 담음
ResponseStatusExceptionResolver 코드를 확인해보면 결국 response.sendError(statusCode, resolvedReason) 를 호출
sendError(400) 를 호출했기 때문에 WAS에서 다시 오류 페이지( /error )를 내부 요청

✔ ApiExceptionController - 추가

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

실행
http://localhost:8080/api/response-status-ex1?message=

{
    "timestamp": "2024-01-18T16:09:11.075+00:00",
    "status": 400,
    "error": "Bad Request",
    "exception": "hello.exception.exception.BadRequestException",
    "message": "잘못된 요청 오류",
    "path": "/api/response-status-ex1"
}

✔ 메시지 기능

reason 을 MessageSource 에서 찾는 기능도 제공
reason = "error.bad"

⚡ BadRequestException

package hello.exception.exception;

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

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

🔶 messages.properties

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

메시지 사용 결과

{
    "timestamp": "2024-01-18T16:18:52.828+00:00",
    "status": 400,
    "error": "Bad Request",
    "exception": "hello.exception.exception.BadRequestException",
    "message": "잘못된 요청 오류입니다. 메시지 사용",
    "path": "/api/response-status-ex1"
}

⚡ ResponseStatusException

@ResponseStatus 는 개발자가 직접 변경할 수 없는 예외에는 적용할 수 없음
- 애노테이션을 직접 넣어야 하는데, 내가 코드를 수정할 수 없는 라이브러리의 예외 코드 같은 곳에는 적용할 수 없음
추가로 애노테이션을 사용하기 때문에 조건에 따라 동적으로 변경하는 것도 어려움
- ResponseStatusException 예외 사용

✔ ApiExceptionController - 추가

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

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

⚡ DefaultHandlerExceptionResolver

스프링 내부에서 발생하는 스프링 예외를 해결
파라미터 바인딩 시점에 타입이 맞지 않으면 내부에서 TypeMismatchException 이 발생
- 이 경우 예외가 발생했기 때문에 그냥 두면 서블릿 컨테이너까지 오류가 올라가고, 결과적으로 500 오류가 발생
파라미터 바인딩은 대부분 클라이언트가 HTTP 요청 정보를 잘못 호출해서 발생하는 문제
- HTTP 에서는 이런 경우 HTTP 상태 코드 400을 사용하도록 되어 있음
DefaultHandlerExceptionResolver 는 500 오류가 아니라 HTTP 상태 코드 400 오류로 변경

코드 확인

response.sendError(HttpServletResponse.SC_BAD_REQUEST) (400)

결국 response.sendError() 를 통해서 문제 해결
sendError(400) 를 호출했기 때문에 WAS에서 다시 오류 페이지( /error )를 내부 요청

ApiExceptionController - 추가

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

➡ Integer data 에 문자를 입력하면 내부에서 TypeMismatchException 이 발생

{
    "timestamp": "2024-01-18T16:33:30.725+00:00",
    "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'; For input string: \"hello\"",
    "path": "/api/default-handler-ex"
}

⚡ 정리

ExceptionHandlerExceptionResolver
ResponseStatusExceptionResolver ➡ HTTP응답코드변경
DefaultHandlerExceptionResolver ➡ 스프링 내부 예외 처리

HandlerExceptionResolver 를 직접 사용하기는 복잡
API 오류 응답의 경우 response 에 직접 데이터를넣어야 해서 매우 불편하고 번거로움
ModelAndView 를 반환해야 하는 것도 API에는 잘 맞지 않음
- 스프링은 @ExceptionHandler 라는 매우 혁신적인 예외 처리 기능을 제공
- ExceptionHandlerExceptionResolver

📌 @ExceptionHandler

⚡ HTML 화면 오류 VS API 오류

웹 브라우저
- HTML 화면을 제공할 때는 오류가 발생하면 BasicErrorController 를 사용하는게 편함
  - 단순히 5xx, 4xx 관련된 오류 화면을 보여주면 됨
- BasicErrorController 는 이런 메커니즘을 모두 구현해둠

API
- 각 시스템 마다 응답의 모양도 다르고, 스펙도 모두 다른데 예외 상황에 단순히 오류 화면을 보여주는 것이 아니라, 예외에 따라서 각각 다른 데이터를 출력해야 할 수도 있음
- 같은 예외라고 해도 어떤 컨트롤러에서 발생했는가에 따라서 다른 예외 응답을 내려주어야 할 수 있음
  - 한마디로 매우 세밀한 제어 필요

⚡ API 예외처리의 어려운 점

HandlerExceptionResolver 를 떠올려 보면 ModelAndView 를 반환해야 했음
- API 응답에는 필요하지 않음
API 응답을 위해서 HttpServletResponse 에 직접 응답 데이터를 넣어줌
- 매우 불편
특정 컨트롤러에서만 발생하는 예외를 별도로 처리하기 어려움
- ex) 회원을 처리하는 컨트롤러에서 발생 하는 RuntimeException 예외와 상품을 관리하는 컨트롤러에서 발생하는 동일한 RuntimeException 예외를 서로 다른 방식으로 처리하고 싶다면?

⚡ @ExceptionHandler

ExceptionHandlerExceptionResolver
- 스프링은 API 예외 처리 문제를 해결하기 위해 @ExceptionHandler 라는 애노테이션을 사용하는 매우 편리한 예외 처리 기능을 제공
- 기본으로 제공하는 ExceptionResolver 중에 우선순위도 가장 높음
- 실무에서 API 예외 처리는 대부분 이 기능을 사용

⚡ ErrorResult

package hello.exception.exhandler;

import lombok.AllArgsConstructor;
import lombok.Data;

@Data
@AllArgsConstructor
public class ErrorResult {
    private String code;
    private String message;
}

➡ 예외가 발생했을 때 API 응답으로 사용하는 객체

⚡ ApiExceptionV2Controller

package hello.exception.exhandler;

import hello.exception.exception.UserException;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@Slf4j
@RestController
public class ApiExceptionV2Controller {

    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(IllegalArgumentException.class)
    public ErrorResult illegalExHandle(IllegalArgumentException e){
        log.error("[exceptionHandle] ex", e);
        return new ErrorResult("BAD", e.getMessage());

    }

    @ExceptionHandler
    public ResponseEntity<ErrorResult> userExHandle(UserException e){
        log.error("[exceptionHandle] ex", e);
        ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
        return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
    }

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler
    public ErrorResult exHandle(Exception e){
        log.error("[exceptionHandle] ex", e);
        return new ErrorResult("EX", "내부 오류");
    }

    @GetMapping("/api2/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);
    }

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

✔ @ExceptionHandler 예외 처리 방법

@ExceptionHandler 애노테이션을 선언하고, 해당 컨트롤러에서 처리하고 싶은 예외를 지정해주면 됨
- 해당 컨트롤러에서 예외가 발생하면 이 메서드가 호출됨

cf) 지정한 예외 또는 그 예외의 자식 클래스는 모두 잡을 수 있음

@ExceptionHandler(IllegalArgumentException.class)
public ErrorResult illegalExHandle(IllegalArgumentException e) {
    log.error("[exceptionHandle] ex", e);
    return new ErrorResult("BAD", e.getMessage());
}

➡ IllegalArgumentException 또는 그 하위 자식 클래스를 모두 처리 가능

✔ 우선순위

스프링의 우선순위는 항상 자세한 것이 우선권을 가짐
ex) 부모, 자식 클래스가 있고 다음과 같이 예외가 처리됨

@ExceptionHandler(부모예외.class) public String 부모예외처리()(부모예외 e) {}

@ExceptionHandler(자식예외.class) public String 자식예외처리()(자식예외 e) {}

@ExceptionHandler 에 지정한 부모 클래스는 자식 클래스까지 처리 가능
자식예외 가 발생하면 부모 예외처리() , 자식예외처리() 둘다 호출 대상이 됨
둘 중 더 자세한 것이 우선권을 가지므로 자식예외처리() 가 호출됨
물론 부모예외 가 호출되면 부모예외처리() 만 호출 대상이 되므로 부모예외처리() 가 호출됨

✔ 다양한 예외

@ExceptionHandler({AException.class, BException.class})
public String ex(Exception e) {
    log.info("exception e", e);
}

➡ 다양한 예외를 한번에 처리 가능

✔ 예외 생략

@ExceptionHandler
public ResponseEntity<ErrorResult> userExHandle(UserException e) {}

➡ @ExceptionHandler 에 예외를 생략 가능
➡ 생략하면 메서드 파라미터의 예외가 지정됨

✔ 파라미터와 응답

@ExceptionHandler 에는 마치 스프링의 컨트롤러의 파라미터 응답처럼 다양한 파라미터와 응답 지정 가능
공식 메뉴얼

✔ IllegalArgumentException 처리

@ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(IllegalArgumentException.class)
public ErrorResult illegalExHandle(IllegalArgumentException e) {
    log.error("[exceptionHandle] ex", e);
    return new ErrorResult("BAD", e.getMessage());
}

실행 흐름

컨트롤러를 호출한 결과 IllegalArgumentException 예외가 컨트롤러 밖으로 던져짐
예외가 발생했으로 ExceptionResolver 가 작동
➡ 가장 우선순위가 높은 ExceptionHandlerExceptionResolver 가 실행됨
ExceptionHandlerExceptionResolver 는 해당 컨트롤러에 IllegalArgumentException 을 처리 할 수 있는 @ExceptionHandler 가 있는지 확인
illegalExHandle() 를 실행
➡ @RestController 이므로 illegalExHandle() 에도 @ResponseBody 가 적용됨
➡ HTTP 컨버터가 사용되고, 응답이 다음과 같은 JSON으로 반환
@ResponseStatus(HttpStatus.BAD_REQUEST) 를 지정했으므로 HTTP 상태 코드 400으로 응답

결과

{
    "code": "BAD",
    "message": "잘못된 입력 값"
}

⚡ UserException 처리

@ExceptionHandler
public ResponseEntity<ErrorResult> userExHandle(UserException e) {
    log.error("[exceptionHandle] ex", e);
    ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
    return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
}

@ExceptionHandler 에 예외를 지정하지 않으면 해당 메서드 파라미터 예외를 사용
➡ 여기서는 UserException 사용
ResponseEntity 를 사용해서 HTTP 메시지 바디에 직접 응답
➡ 물론 HTTP 컨버터가 사용됨
ResponseEntity 를 사용하면 HTTP 응답 코드를 프로그래밍해서 동적으로 변경할 수 있음
➡ 앞서 살펴본 @ResponseStatus 는 애노테이션이므로 HTTP 응답 코드를 동적으로 변경할 수 없음

⚡ Exception

@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
@ExceptionHandler
public ErrorResult exHandle(Exception e) {
    log.error("[exceptionHandle] ex", e);
    return new ErrorResult("EX", "내부 오류"); 
}

thrownewRuntimeException("잘못된 사용자") 이 코드가 실행되면서, 컨트롤러 밖으로 RuntimeException 이 던져짐
RuntimeException 은 Exception 의 자식 클래스
➡ 이 메서드가 호출
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) 로 HTTP 상태 코드를 500으로 응답

⚡ 기타

✔ HTML 오류 화면

@ExceptionHandler(ViewException.class)
public ModelAndView ex(ViewException e) {
    log.info("exception e", e);
    return new ModelAndView("error");
}

➡ ModelAndView 를 사용해서 오류 화면(HTML)을 응답하는데 사용할 수 있음

📌 @ControllerAdvice

@ExceptionHandler 를 사용해서 예외를 깔끔하게 처리할 수 있게 되었지만, 정상 코드와 예외 처리 코드가 하나의 컨트롤러에 섞여 있음
@ControllerAdvice 또는 @RestControllerAdvice 를 사용하여 둘을 분리

⚡ ExControllerAdvice

package hello.exception.exhandler.advice;

import hello.exception.exception.UserException;
import hello.exception.exhandler.ErrorResult;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestControllerAdvice;

@Slf4j
@RestControllerAdvice
public class ExControllerAdvice {

    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(IllegalArgumentException.class)
    public ErrorResult illegalExHandle(IllegalArgumentException e){
        log.error("[exceptionHandle] ex", e);
        return new ErrorResult("BAD", e.getMessage());
    }

    @ExceptionHandler
    public ResponseEntity<ErrorResult> userExHandle(UserException e){
        log.error("[exceptionHandle] ex", e);
        ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
        return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
    }

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler
    public ErrorResult exHandle(Exception e){
        log.error("[exceptionHandle] ex", e);
        return new ErrorResult("EX", "내부 오류");
    }
}

ApiExceptionV2Controller 코드에 있는 @ExceptionHandler 모두 제거

package hello.exception.exhandler;

import hello.exception.exception.UserException;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@Slf4j
@RestController
public class ApiExceptionV2Controller {

    @GetMapping("/api2/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);
    }

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

⚡ @ControllerAdvice

@ControllerAdvice : 대상으로 지정한 여러 컨트롤러에 @ExceptionHandler , @InitBinder 기능을 부여해줌
@ControllerAdvice 에 대상을 지정하지 않으면 모든 컨트롤러에 적용됨
➡ 글로벌 적용
@RestControllerAdvice 는 @ControllerAdvice 와 같고, @ResponseBody 가 추가되어 있음
➡ @Controller , @RestController 의 차이와 같다.

✔ 대상 컨트롤러 지정 방법

 // Target all Controllers annotated with @RestController
 @ControllerAdvice(annotations = RestController.class)
 public class ExampleAdvice1 {}

 // Target all Controllers within specific packages
 @ControllerAdvice("org.example.controllers")
 public class ExampleAdvice2 {}

// Target all Controllers assignable to specific classes
@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})
public class ExampleAdvice3 {}

스프링 공식 문서 참고

특정 애노테이션이 있는 컨트롤러를 지정할 수 있고, 특정 패키지를 직접 지정 할 수도 있음
패키지 지정의 경우 해당 패키지와 그 하위에 있는 컨트롤러가 대상이 됨
➡ 특정 클래스도 지정 가능
대상 컨트롤러 지정을 생략하면 모든 컨트롤러에 적용됨

김영한님의 <스프링 MVC 2편 - 백엔드 웹 개발 활용 기술>을 수강하고 작성한 글입니다

PREV

[스프링 MVC 2편] 8. 예외 처리와 오류 페이지

📌 서블릿 예외 처리 ⚡ 서블릿의 예외처리 2가지 방법 Exception (예외) response.sendError(HTTP 상태 코드, 오류메시지) ⚡ Exception(예외) 자바 직접 실행 자바의 메인 메서드를 직접 실행하는 경우 main

nyeroni.tistory.com

NEXT

[스프링 MVC 2편] 10. 스프링 타입 컨버터

📌 스프링 타입 컨버터란? 문자를 숫자로 변환하거나, 반대로 숫자를 문자로 변환해야 하는 것 처럼 애플리케이션을 개발하다 보면 타입을 변환해야 하는 경우 사용 ⚡ 문자 타입을 숫자 타입

nyeroni.tistory.com

728x90

LIST

저작자표시 비영리 변경금지

'인프런 Spring 강의 정리 > 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술' 카테고리의 다른 글

[스프링 MVC 2편] 11. 파일 업로드 (1)	2024.01.26
[스프링 MVC 2편] 10. 스프링 타입 컨버터 (1)	2024.01.26
[스프링 MVC 2편] 8. 예외 처리와 오류 페이지 (1)	2024.01.25
[스프링 MVC 2편] 7. 로그인 처리 2 - 필터, 인터셉터 (1)	2024.01.25
[스프링 MVC 2편] 6. 로그인 처리1 - 쿠키, 세션 (1)	2024.01.25

예롱이의 개발 블로그

CATEGORIES

[스프링 MVC 2편] 9. API 예외 처리 /category/%EC%9D%B8%ED%94%84%EB%9F%B0%20Spring%20%EA%B0%95%EC%9D%98%20%EC%A0%95%EB%A6%AC/%EC%8A%A4%ED%94%84%EB%A7%81%20MVC%202%ED%8E%B8%20-%20%EB%B0%B1%EC%97%94%EB%93%9C%20%EC%9B%B9%20%EA%B0%9C%EB%B0%9C%20%ED%99%9C%EC%9A%A9%20%EA%B8%B0%EC%88%A0

📌 서블릿 오류 페이지 방식으로 처리

⚡ WebServerCustomizer 다시 동작

✔ ApiExceptionController - API 예외 컨트롤러

Postman으로 테스트

✔ ErrorPageController - API 응답 추가

📌 스프링 부트 기본 오류 처리

BasicErrorController 코드

✔ 스프링 부트의 예외 처리

Postman으로 실행

⚡ Html 페이지 VS API 오류

📌 HandlerExceptionResolver

⚡ 상태코드 변환

ApiExceptionController - 수정

⚡ HandlerExceptionResolver

✔ ExceptionResolver 적용 전

✔ ExceptionResolver 적용 후

⚡ HandlerExceptionResolver - 인터페이스

✔ MyHandlerExceptionResolver

✔ 반환 값에 따른 동작 방식

✔ ExceptionResolver 활용

✔ WebConfig - 수정

⚡ 활용

⚡ UserException

✔ ApiExceptionController - 예외 추가

⚡ UserHandlerExceptionResolver

⚡ WebConfig에 UserHandlerExceptionResolver 추가

⚡ 정리

📌 스프링이 제공하는 ExceptionResolver

✔ ExceptionHandlerExceptionResolver

✔ ResponseStatusExceptionResolver

✔ DefaultHandlerExceptionResolver

✔ ResponseStatusExceptionResolver

⚡ BadRequestException

✔ ApiExceptionController - 추가

✔ 메시지 기능

⚡ BadRequestException

메시지 사용 결과

⚡ ResponseStatusException

✔ ApiExceptionController - 추가

⚡ DefaultHandlerExceptionResolver

코드 확인

ApiExceptionController - 추가

⚡ 정리

📌 @ExceptionHandler

⚡ HTML 화면 오류 VS API 오류

⚡ API 예외처리의 어려운 점

⚡ @ExceptionHandler

⚡ ErrorResult

⚡ ApiExceptionV2Controller

✔ @ExceptionHandler 예외 처리 방법

✔ 우선순위

✔ 다양한 예외

✔ 예외 생략

✔ 파라미터와 응답

✔ IllegalArgumentException 처리

실행 흐름

결과

⚡ UserException 처리

⚡ Exception

⚡ 기타

✔ HTML 오류 화면

📌 @ControllerAdvice

⚡ ExControllerAdvice

ApiExceptionV2Controller 코드에 있는 @ExceptionHandler 모두 제거

⚡ @ControllerAdvice

✔ 대상 컨트롤러 지정 방법

'인프런 Spring 강의 정리 > 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술' 카테고리의 다른 글

BELATED ARTICLES

티스토리툴바

[스프링 MVC 2편] 9. API 예외 처리
/category/%EC%9D%B8%ED%94%84%EB%9F%B0%20Spring%20%EA%B0%95%EC%9D%98%20%EC%A0%95%EB%A6%AC/%EC%8A%A4%ED%94%84%EB%A7%81%20MVC%202%ED%8E%B8%20-%20%EB%B0%B1%EC%97%94%EB%93%9C%20%EC%9B%B9%20%EA%B0%9C%EB%B0%9C%20%ED%99%9C%EC%9A%A9%20%EA%B8%B0%EC%88%A0