Home API에서의 예외 처리
Post
Cancel

API에서의 예외 처리

Posted Oct 3, 2023
By
28 min read

HTML 페이지의 경우 4xx, 5xx와 같은 오류페이지만 있으면 대부분의 문제를 해결할 수 있다. 단순히 보여주면 된다.

하지만 API의 경우 생각할 내용이 많다. API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려주어야 한다.

하던 방식으로 API에 적용해보자.

1
2
3
4
5
6
7
8
9
10
11
12
13

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

이전 포스트에서 작성했던 에러페이지를 등록하는 WebServerCustomizer를 살린다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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

id를 파라미터로 입력받아 객체를 반환해 JSON 데이터를 응답에 담아 전달한다.

/api/members/ex 를 요청해 예외를 받아보자.

당연히 위에서 살린 WebServerCoustomizer에 등록되어 있는 대로 500 오류가 발생하면 WAS는 “/error-page/500”를 요청하게 된다.

해당 부분은 ErrorController에 있고, 반환값으로 500.html을 반환하여 오류페이지 뷰를 반환하게 되는 것이다.

웹 브라우저에서의 통신이 아닌 API 통신하고 있기 때문에 오류페이지 HTML이 반환되면 안된다. 클라이언트는 정상 요청이든, 오류 요청이든 JSON이 반환되기를 원한다.

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

API 오류처리 서블릿 활용

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
31
32
33
34

@Slf4j  
@Controller  
public class ErrorPageController {  
  
	//RequestDispatcher 상수로 정의되어 있음  
	public static final String ERROR_EXCEPTION = "javax.servlet.error.exception";  
	public static final String ERROR_EXCEPTION_TYPE = "javax.servlet.error.exception_type";  
	public static final String ERROR_MESSAGE = "javax.servlet.error.message";  
	public static final String ERROR_REQUEST_URI = "javax.servlet.error.request_uri";  
	public static final String ERROR_SERVLET_NAME = "javax.servlet.error.servlet_name";  
	public static final String ERROR_STATUS_CODE = "javax.servlet.error.status_code";

	@RequestMapping("/error-page/500")  
	public String errorPage500(HttpServletRequest request, HttpServletResponse response) {  
		log.info("errorPage 500");  
		printErrorInfo(request);  
		return "error-page/500";  
	}  
	  
	@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, HttpStatus.valueOf(statusCode));  
	}
}

ErrorController에 500 오류를 처리하는 부분이 두 부분이 있다.

  • produces = MediaType.APPLICATION_JSON_VALUE
    • 클라이언트가 요청하는 HTTP Header의 Accept 값이 application/json일 때 해당 메서드가 호출된다.
    • 즉 클라이언트가 받고 싶은 미디어타입이 json이면 해당 메서드가 호출된다.
  • 응답 데이터
    • Map을 만들고 status, message 키에 값을 할당했다.
    • Jackson 라이브러리가 Map을 JSON 구조로 변환시켜준다.

ResponseEntity<>

API 통신을 할 때, HTTP 상태코드를 변경하지 않아도 되는 상황에는 @ResponseBody를 사용해 객체를 넘겨 JSON을 반환하게 하거나, @RestController로 @ResponseBody를 생략하고 객체를 넘겨 JSON을 반환한다. @ResponseStatus(HttpStatus.OK)로 상태코드를 전달할 수 있다.

단, 보통 HTTP 상태코드도 변경해야할 때 ResponseEntity<>를 반환하여 사용할 수 있다. 특정 조건에 따라 상태코드를 변경할 수 있다는 장점이 있다.

여기서는 Map을 넣어 반환했지만, 객체를 넣어도 같다. Member 객체를 넣어 반환하면 Member객체를 JSON으로 변환한 내용과 HTTP 상태코드를 전달하는 것이다.

(상태코드는 생략 가능하다.)

API 오류처리 스프링 부트

API 예외 처리도 스프링 부트가 제공하는 기본 오류 방식을 사용할 수 있다. 우선 스프링 부트가 제공하는 BasicErrorController 코드를 봐보자.

1
2
3
4
5

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

@ReqeustMapping
public ResponseEntity<Map<String, Object>> error(HttpServletReqeust request) {}

/error 의 동일한 경로를 처리하는 errorHtml(), error() 두 메서드를 확인할 수 있다. produces로 Accept 헤더 값이 text/html 인 경우 errorHtml()을 호출해 view를 제공하도록 되어있다.

  • 스프링 부트의 예외 처리
    • 이전 포스트에서 보다시피 스프링 부트의 기본 설정은 오류 발생 시 /error를 오류 페이지로 요청한다. 오류 처리 컨트롤러는 이 경로를 기본으로 받는다.

우선 위의 서블릿에서 WebServerCustomizer를 비활성화하고 다시 예외를 발생시키는 요청을 해보자. ( /api/members/ex )

위와 같은 값들이 담긴 JSON 데이터를 반환하게 된다.

( 즉, 아무것도 설정을 건드리지 않고 Accept가 application/json으로 되어있으면 exception이 발생되었을 때, /error가 요청되어 위와 같은 메시지들을 담아 반환해준다. )

만약 Accept를 text/html로 한다면?

당연히 우리가 만들었던 /templates/error/500.html (기본 경로) 이 반환된다.

HTML 페이지 vs API 오류 (스프링부트)

BasicErrorController를 확장하면 JSON 메시지도 변경할 수 있다. (API 오류는 참고로 아래에 설명할 @ExceptionHandler가 제공하는 기능을 사용하는 것이 낫다.)

일단 BasicErrorController는 HTML 페이지를 제공하는 경우 매우 편리하다. 하지만 API 오류 처리는 다른 차원의 이야기이다. API 마다, 각각의 컨트롤러 예외 마다 서로 다른 응답 결과를 출력해야 할 수도 있다.

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

따라서 위 방법은 HTML 화면을 처리할 때 사용하고, API 오류 처리는 @ExceptionHanlder를 사용한다.

API 예외처리 - HandlerExceptionResolver

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

발생하는 예외에 따라 400, 404 등등 다른 상태코드도 처리하고 싶은 경우가 있따. 즉 오류 메시지, 형식 등을 API마다 다르게 처리하고 싶을 수 있다.

예를 들어 IllegalArgumentException을 처리하지 못해 컨트롤러 밖으로 넘어가는 일이 발생하면 클라이언트가 잘못한 것임에도 500으로 처리된다. 400으로 처리하고 싶다면 어떻게 해야할까.

우선 테스트를 위해 /api/members/bad 라고 입력하면 IllegalArgumentException이 발생하도록 해본다.

실행해보면 당연히 상태코드 500으로 반환된다.

HandlerExceptionResolver

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

그것이 HandlerExceptionResolver이고 줄여서 ExceptionResolver라고 한다.

적용하기 전에는 인터셉터의 preHandle은 실행되고 컨트롤러에서 예외가 발생하면 당연히 postHandler은 호출되지 않고, afterCompletion이 실행된다. 그리고 예외가 WAS에 전달된다.

하지만 적용 후에는 마찬가지로 postHandle은 호출되지 않지만, 대신 ExceptionResolver가 호출된다. 컨트롤러에서 발생한 예외를 가로채 해결을 시도하는 것이라고 보면 된다.

HandlerExceptionResolver 인터페이스

1
2
3
4
5

public interface HandlerExceptionResolver {
	
	ModelAndView resolveException(HttpServletRequest request,
			HttpServletResponse response, Object handler, Exception ex) {}
}
  • handler : 컨트롤러 정보
  • Exception ex : 핸들러(컨트롤러)에서 발생한 예외

MyHandlerExceptionResolver

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@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을 처리해 정상 흐름처럼 변경하는 것이 목표이다.
    • 위 코드에서는 IllegalArgumentException이 발생하면 response.sendError(400)을 호출해 HTTP 상태코드를 400으로 지정하고 빈 ModelAndView를 반환한다.
  • 반환 값에 따른 동작 방식
    • 빈 ModelAndView : 뷰를 렌더링하지 않고 정상 흐름으로 서블릿이 리턴한다.
    • ModelAndView 지정 : 뷰를 렌더링한다.
    • null 반환 : 다음 ExceptionResolver를 찾아 실행한다. 만약 처리할 수 있는 ExceptionResolver가 없으면 예외 처리가 되지 않고, 기존에 발생한 예외를 서블릿 밖으로 던진다. (500)
  • ExceptionResolver의 활용
    • 예외 상태 코드 변환
      • 예외를 response.sendError() 호출로 변경해 서블릿에서 상태 코드에 따른 오류를 처리하도록 위임.
      • 이후 WAS는 서블릿 오류 페이지를 찾아 내부 호출한다.
    • 뷰 템플릿 처리
      • ModelAndView에 값을 채워 예외에 따른 새로운 오류 화면 뷰 렌더링 해서 고객에게 제공 가능.
    • API 응답 처리.
      • response.getWriter().println(“hello”)처럼 응답 바디에 직접 데이터를 넣어주는 것도 가능하다. 저 방식으로 JSON으로 응답하면 API 응답처리도 가능하다. 번거롭겠지만.

물론 위에서 만든 Resolver를 사용하려면 등록해주어야 한다.

WebConfig (인터셉터, 필터 등등) 에서 등록한다.

1
2
3
4
5
6
7

@Configuration  
public class WebConfig implements WebMvcConfigurer {
	@Override  
	public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {  
		resolvers.add(new MyHandlerExceptionResolver());  
	}
}

HandlerExceptionResolver의 활용

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

이 과정들은 어떻게 보면 복잡하다. ExceptionResolver를 활용하면 예외가 발생했을 때 이런 복잡한 과정 없이 이 Resolver 부분에서 문제를 해결할 수 있다.

우선 아래 사용자 정의 예외를 하나 추가한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

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

그리고 컨트롤러에서 /api/members/user-ex 를 요청하면 위의 예외를 날리도록 한다.

UserHandlerExceptionResolver

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
31
32
33
34
35

@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);  
				}  
			} else {  
			// TEXT/HTML  
			return new ModelAndView("error/500");  
			}  
		} catch (IOException e) {  
			log.error("resolver ex", e);  
		}  
	  
		return null;  
	}  
}

마찬가지로 새로운 Resolver이므로 WebConfig에 추가해준다.

컨트롤러에서 예외가 발생해도 ExceptionResolver에서 예외를 처리해버린다. 따라서 예외가 발생해도 서블릿 컨테이너까지 예외가 전달되지 않고, (인터셉터의 posthandle이 호출되는 시점과 비슷하기 때문) 스프링 MVC에서 예외 처리는 끝난다.

결과적으로 WAS 입장에서는 정상 처리가 된 것이다. 이렇게 예외를 위와 같이 한 곳에서 모두 처리할 수 있는 것이 핵심이다.

서블릿 컨테이너까지 예외가 올라가면 복잡하고 지저분하게 추가 프로세스가 실행된다. 반면 ExceptionResolver를 이용하면 예외처리가 깔끔하다.

하지만 이 직접 구현함에있어 코드가 상당히 복잡하고 번거로운 것을 볼 수 있다. 이제 스프링이 제공하는 ExceptionResolver를 이용해본다.

스프링이 제공하는 ExceptionResolver

스프링 부트가 기본으로 제공하는 ExceptinoResolver는 아래와 같다.

HandlerExceptionResolverComposite에 아래 순서대로 등록한다.

  • ExceptionHandlerExceptionResolver
    • @ExceptionHandler 을 처리한다. API 예외처리는 대부분 이 기능으로 해결한다.
  • ResponseStatusExceptionResolver
    • HTTP 상태 코드를 지정해준다.
    • ex) @ResponseStatus(value = HttpStatus.NOT_FOUND)
  • DefaultHandlerExceptionREsolver
    • 스프링 내부 기본 예외를 처리한다.

ResponseStatusExceptionResolver

예외에 따라 HTTP 상태 코드를 지정해준다.

  • @ResponseStatus가 달려있는 예외
  • ResponseStatusException 예외

이 두 가지 경우를 처리한다.

1
2
3

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

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

해당 코드를 확인해보면 결국 response.sendError(statusCode, resolvedReason)를 호출한다. sendError(400)를 호출했기 때문에 WAS에서 다시 오류페이지 /error를 내부 요청한다.

  • reason = “error.bad” 처럼 MessageSource에서 찾는 기능도 제공한다. (messages.properties)

애노테이션을 쓰지 않는 경우

@ResponseStatus는 개발자가 직접 변경할 수 없는 예외에는 적용할 수 없다. (애노테이션을 넣어야 하는데 코드를 수정할 수 없는 라이브러리의 예외 코드 같은 곳에 적용 불가.)

추가로 애노테이션을 사용해 조건에 따라 동적으로 변경하기도 어렵다. 이 때는 ResponseStatusException 예외를 사용하면 된다.

1
2
3
4
5

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

DefualtHandlerExceptionResolver

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

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

그런데 파라미터 바인딩은 대부분 클라이언트가 HTTP 요청 정보를 잘못 호출해서 발생하는 문제이다. HTTP 에서는 이런 경우 HTTP 상태코드 400을 사용한다.

DefaultHandlerExceptionResolver는 이것을 500 오류가 아닌 400 오류로 변경해준다. 스프링 내부 오류를 어떻게 처리할 지 수 많은 내용이 정의되어 있다.

얘도 TypeMismatch를 예로 들면 결국 response.sendError(400)을 호출한다. 따라서 WAS에서 다시 오류 페이지 /error를 내부 요청하는 것이다.

@ExceptionHandler

API 예외 처리의 어려운 점

  • HandlerExceptionResolver를 떠올려보면 ModelAndView를 반환해야 했다. 이 것은 API 응답에 필요 없다.
  • API 응답을 위해 HttpServletResponse에 직접 응답 데이터를 넣어주기도 했다. 이것은 매우매우 불편하다.
  • 특정 컨트롤러에서만 발생하는 예외를 별도로 처리하기 어렵다.
    • (Resolver는 instanceof RuntimeException 같이 오류마다 처리하는 방식으로 했었다.)
    • 예를 들면 회원을 처리하는 컨트롤러에서 발생하는 RuntimeException 예외와 상품을 관리하는 컨트롤러에서 발생하는 동일한 RuntimeException 예외를 서로 다른 방식으로 처리하고 싶다면?

@ExceptionHandler

저렇게 어려운 부분을 해결하기 위해 이 애노테이션이 제공된다.

ExceptionHandlerExceptionResolver를 기본으로 제공하고 기본으로 제공하는 ExceptionResolver 중 우선순위도 가장 높다.

실무에서 API 예외 처리는 대부분 이 기능을 사용하게 된다.

예시

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
31
32
33
34
35
36
37
38
39
40
41

@Slf4j  
@RestController  
public class ApiExceptionV2Controller {  
  
	@ExceptionHandler(IllegalArgumentException.class)  
	public ErrorResult illegalExHandler(IllegalArgumentException e) {  
		log.error("[exceptionHandler] ex", e);  
		return new ErrorResult("BAD", e.getMessage());  
	}  
	  
	@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;  
	}  
	  
	@Data  
	@AllArgsConstructor  
	public class ErrorResult {  
		private String code;  
		private String message;  
	}  
}

@ExceptionHandler 애노테이션을 사용하면 해당 컨트롤러에서 예외가 발생했을 때 해당 메서드가 호출되는 방식이다. @RestController이기 때문에 ErrorResult 객체가 JSON으로 반환된다.

참고로 지정한 예외 또는 그 예외의 자식 클래스는 모두 잡을 수 있다. (위의 예제로 보면 IllegalArgumentException 하위 자식 클래스 모두 처리)

정확한 순서

/api2/members/bad 요청으로 IllegalArgumentException이 발생하면 바로 @ExceptionHandler가 붙어있는 메서드가 호출되는 것이 아니다.

컨트롤러에서 예외가 발생 -> ExceptionResolver를 통한 예외 해결 시도 (여기서의 ExceptionResolver가 ExceptionHandlerExceptionResolver인 것이다.) -> 이 Resolver가 @ExceptionHandler를 찾아 메서드를 호출하는 것이다.

참고

위의 예시 코드에서 @ExceptionHandler가 붙은 메서드는 ErrorResult를 반환하는데 오류를 중간에 잡아서 정상흐름으로 바꾸는 것이라 실제 반환되는 것을 보면 HTTP Status가 200인 것을 볼 수 있다.

예외상태코드를 바꾸고 싶다면 @ResponseStatus(HttpStatus.BAD_REQUEST) 사용하면 된다.

1
2
3
4
5
6
7

@ExceptionHandler // 매개변수 오류 동일하면 생략 가
public ResponseEntity<ErrorResult> userExHandler(UserException e) {
	log.error("[exceptionHandler] ex", e);
	ErrorResult errorResult = new ErrorResult("USER-EX", "사용자 오류");
	
	return new ResponseEntity(errorResult, HttpStatus.BAD_REQUEST);
}

위와 같이 ResponseEntity를 써도 당연히 된다.

우선순위

항상 자세한 것이 우선권을 가진다. Exception의 자식클래스 RuntimeException이 있는데 RuntimeException이 따로 구현되어 있다면 자식이 호출된다.

다양한 예외

아래와 같이 예외를 한 번에 처리할 수 있다.

1
2
3
4

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

파라미터와 응답

스프링의 컨트롤러의 파라미터 응답처럼 다양한 파라미터와 응답을 (return 값) 지정할 수 있다.

공식 메뉴얼

1
2
3
4
5

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

ModelAndView를 반환해 오류 화면을 응답하는데 사용할 수도 있다. 물론 잘 사용하지는 않는다.

@ControllerAdvice

@ExceptionHandler를 사용해 예외를 처리하는 것 까진 편하고 좋다. 다만 정상 코드와 예외 처리 코드가 하나의 컨트롤러에 섞여있다는 단점이 있다.

@ControllerAdvice 또는 @RestControllerAdvice를 사용하면 분리할 수 있다.

1
2
3
4
5
6
7
8
9
10

@Slf4j  
@RestControllerAdvice  
public class ExControllerAdvice {  
  
	@ExceptionHandler(IllegalArgumentException.class)  
	public ErrorResult illegalExHandler(IllegalArgumentException e) {  
		log.error("[exceptionHandler] ex", e);  
		return new ErrorResult("BAD", e.getMessage());  
	}    
}

단순히 위와 같은 클래스만 만들어줘도 바로 적용된다.

이유를 보자.

  • @ControllerAdvice는 대상으로 지정한 여러 컨트롤러에 @ExceptionHandler, @InitBinder 기능을 부여해주는 역할을 한다.
  • @ControllerAdvice에 대상을 지정하지 않으면 모든 컨트롤러에 적용된다. (그래서 적용됐던 것이다.)
  • @RestControllerAdvice는 @ControllerAdvice와 같지만 @ResponseBody가 추가된 것이다.

지정 방법

1
2
3
4
5

@ControllerAdvice(annotations = RestController.class)

@ControllerAdvice("org.example.controllers")

@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})

공식 문서 참고

예시 코드와 같이 특정 애노테이션이 있는 컨트롤러를 지정할 수 있고, 특정 패키지를 지정할 수도 있다. 패키지 지정의 경우 해당 패키지와 그 하위에 있는 컨트롤러가 대상이다. 특정 클래스도 지정할 수 있다.

Spring, 스프링 MVC 활용
java Spring SpringBoot
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents