스프링 스터디 ; API 예외처리

MINJU·2022년 4월 3일
스프링
0

스프링

목록 보기
9/15

강의 링크

개요

API 예외 처리는 많은 부분을 고려해야합니다. 각 API마다 규약이 다르므로 error 상황에 맞는 응답을 정해야하고 JSON으로 데이터를 전송해야만합니다.

서블릿 오류 페이지

기존 예제에서 예외 페이지를 WebServerCustomizer에 등록하고 ErrorPageController에서 예외를 처리했습니다.

✔ WebServerCustomizer


@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, "/errorpage/500");
    
    // public ErrorPage(HttpStatus status, String path) {
	//		this.status = status;
	//		this.exception = null;
	//		this.path = path;
	// }
    
	factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
}
}

__✔ ApiExceptionController

@RestController
@Slf4j
public class ApiExceptionController {
    @GetMapping("/api/members/{id}")
    public MemberDto getMember_origin(@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;
}
}

이러한 상황에서 API 호출시 오류가 발생하면 미리 만드어둔 오류 페이지 HTML이 반환됩니다. (클라이언트는 JOSN 반환을 기대합니다.) 따라서 오류 페이지 컨트롤러도 JSON 응답을 할 수 있도록 수정해야합니다.

✔ ErrorPageController

@RequestMapping(value="/error-page/500", produces=MediaType.APPLICATION_JSON_VALUE)
// 클라이어늩가 요청하는 HTTP 헤더의 값이 application/json일때 해당 메서드가 호출됩니다.

// 이때 ResponseEntity는 HttpRequest에 대한 응답 데이터를 포함하는 클래스로
// HttpStatus, HttpHeaders, HttpBody를 포함한다.
public ResponseEntity<Map<String, Object>> errorPage500Api(HttpServletRequest request, HttpServletResponse response){
	log.info("API errorPage 500");
    
    Map<String, Object> result= new HashMap<>();
    
    //public static final String ERROR_STATUS_CODE= "javax.servlet.error.status_code";
    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);
    
    
   // ResponseEntity를 사용해서 응답하므로 메시지 컨버터가 동작하면서 클라이언트에 JSON이 반환된다.
    return new ResponseEntity(result, HttpStatus.valueOf(statusCode));
}

new ResponseEntity(result, HttpStatus.valueOf(statusCode));코드 분석
: valueOf(int StatusCode)는 Return the HttpStatus enum constant with the specified numeric value.(반환타입은 HttpStatus)
: result은 entity body에
: HttpStatus.valueOf(statusCode)는 status에

위와 같은 설정을 마치면 API 오류시 다음과 같은 응답을 받을 수 있게 된다.

API 예외 처리

: 스프링부트가 제공하는 BasicErrorController코드를 보자.


동일한 /error경로를 처리하는 두 메소드를 확인할 수 있다. errorHtml()은 클라이언트 요청의 accept 헤더 값이 text/html인 경우 호출되어서 view를 제공하고 error()은 그 이외의 경우에 호출되면서 ResponseEntity로 HTTP body에 JSON 데이터를 반환한다.

스프링 부트의 기본 설정은 오류 발생시 /error를 오류 페이지로 요청한다. server.error.path로 수정가능하기는 하다. (그리고 BasicErrorController는 /error url을 받는 컨트롤러입니다.)

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

옵션을 추가하면 더 자세한 오류 정보를 추가할 수 있는데 보안상 위험하므로 나머지 정보는 로그로 확인하는 것이 더 좋습니다.

추가

참조 블로그

서블릸이 예외를 받는 경우는 두 가지 입니다.
첫 번째로 서블릿 내에서 발생한 예외가 서블릿 밖으로 나온 경우입니다.

이 경우 예외가 서블릿 밖으로 빠져나오면 WAS가 이 예외를 받게 되는데, WAS는 이미 만들어진 예외 페이지가 있다면 거기로 다시 url 요청 메시지를 보내게 되고, 만약 없다면 톰캣이 기본으로 제공하는 오류 페이지에 HTTP 상태코드 500으로 응답을 보내게 됩니다.

두 번째로 response.sendError() 메서드가 호출된 경우입니다.

먼저 에러가 발생하면 이를 try catch로 받고 sendError()에 Http 상태코드, 에러 메시지를 담아서 호출합니다.(당장 오류가 발생하는 것을 막습니다.)
그러면 서버는 정상적으로 서블릿 -> 인터셉터 -> 필터 -> WAS까지 응답이 가고, WAS가 sendError()의 호출 유무를 확인하고 호출된 적이 있으면 에러처리를 하고 그렇지 않으면 정상적으로 클라이언트에게 HTTP 응답 메시지를 보냅니다.

HTMP 페이지 vs API오류

BasicErrorController를 확장하면 JSON 메시지도 변경할 수 있습니다. 근데 API 오류 처리의 경우에는 API 마다, 각 컨트롤러마다, 각 예외 마다 서로 다른 응답 결과를 출력해야하는 경우가 있기 때문에 API의 경우에서는 BasicErrorController보다는 @ExceptionHandler를 사용하여 복잡한 API 오류를 처리합니다.

HandlerExceptionResolver 시작

: 예외가 발생해서 서블릿을 넘어 WAS까지 전달되면, HTTP 상태코드가 500으로 처리됩니다. 근데 우리는 예외에 따라서 다른 상태 코드로 처리하고 싶고 오류 메시지 및 형식을 API마다 다르게 처리하고 싶습니다.

상태 코드 변환

: 스프링 MVC는 컨트롤러 밖으로 예외가 던져진 경우 

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

예외를 해결하고 동작을 새로 정의할 수 있는 방법을 제공합니다. 컨트롤러 밖으로 던져진 예외를 해결하고 동작 방식을 변경하고 싶으면 HandlerExceptionResolver를 사용하면 됩니다.


HandlerExceptionResolver 인터페이스는 이와 같습니다. 이때 handler는 핸들러(컨트롤러) 정보를 담고 있고 Exception ex 핸들러에서 발생한 예외를 담고 있습니다.

✔ MyHandlerExceptionResolver

@Slf4j
public class MyHandlerExceptionResolver implements HandlerExceptionResolver{
	@Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exceptionex){
    	tryP
        	if(ex instanceof IllegalArgumentException){
            	log.info("IllegalArgumentException resolver to 400);
                response.sendError(HttpServletResponse.SC_BAD_REQUEST, exx.getMessage());
                return new ModelAndView();
                }
       }catch(IOException e){
       		log.error("resolver ex",e);
            }
       return null;
}}

ExceptionResolver는 ModelAndView를 반환하여 정상흐름처럼 변경합니다. 위의 경우 IllegalArgumentException이 발생하면 response.sednError(400)을 호출해서 HTTP 상태코드를 400으로 지정하고 빈 ModelAndView를 반환합니다.

HandlerExceptionResolver 반환값에 따른 DispatcherServlet의 동작방식은

  • 빈 ModelAndView는 뷰를 렌더링하지 않고, 정상 흐름으로 서블릿이 리턴됩니다.
  • ModelAndView 지정 ModelAndView에 view, model 등의 정보를 지정하면 뷰를 렌더링합니다.
  • null 을 반환하면 다음 순서의 ExceptionResolver를 찾아서 실행합니다. 만약 처리할 수 있는 resolver가 없으면 예외 처리가 안되고 기존에 발생한 예외를 서블릿 밖으로 던집니다.

ExceptionResolver 활용

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

    • 이후 WAS는 서블릿 오류 페이지를 찾아서 내부 호출.(ex. 스프링 부트가 기본으로 설정한 /error가 호출됨)

  • 뷰 템플릿 처리
    - ModelAndView에 값을 채워서 예외에 따른 새로운 오류 화면 뷰를 렌더링

  • API 응답 처리
    -response.getWriter().println("hello") 처럼 HTTP 응답 바디에 직접 데이터를 넣어주는 것도 가능

등록하는 방식은 다읍과 같습니다.(WebConfig 수정)

@Override
public void ExtendHandlerExceptionResolvers(List<HandelerExceptionResolver> resolvers){
	resolvers.add(new MyHandlerExceptionResolver());
    }

HandlerExceptionResolver 활용

: 예외가 발생하면 WAS까지 갔다가 WAS에서 다시 /error 호출하는 과정은 넘 복잡합니다.
: 여기에서 ExceptionResolver 를 활용하면 좋습니다.

: 예제에서는 UserException이라는 사용자 정의 예외를 선언했습니다.
: 이에 맞게 예외를 던지도록 Controller를 추가했습니다.

@GetMapping("/api/members/{id}")
public MemberDto getMember(@PathVariable("id") String id){
	if(id.equals("user-ex"){
    	throws new UserException("사용자 오류");
        }
  ...

이 예외를 처리하는 Resolver는 다음과 같습니다.
✔ UserHandelrExceptionResolver

@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);
            
            /// application/json 요청이면
			if ("application/json".equals(acceptHeader)) {
				Map<String, Object> errorResult = new HashMap<>();
				errorResult.put("ex", ex.getClass());
				errorResult.put("message", ex.getMessage());
                
                //String으로 값을 변환!(Map -> String)
				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;
	}
}

WebConfig에 UserHandlerExceptionResolver 추가

@Override
public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers){
	resolvers.add(new MyHandlerExceptionResolver());
    resolvers.add(new UserHandlerExceptionResolver());
}

참조블로그

ExceptionResolver를 활용하면 컨트롤러에서 예외가 발생해도 ExceptionResolver에서 예외를 처리해버립니다. 따라서 예외가 발생해도 서블릿 컨테이너까지 예외가 전달되지 않고 스프링 MVC에서 예외 처리는 끝이 납니다. 하지만 위와 같이 ExceptionResolver를 구현하는 것은 상당히 복잡합니다. 이의 대안으로 스프링이 제공하는 ExceptionResolver를 사용합니다.

스프링이 제공하는 ExceptionResolver1

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

  1. ExceptionHandlerExceptionResolver
  2. ResponseStatusExceptionResolver
  3. DefaultHandlerExceptionResolver

ExceptionHandlerExceptionResolver
@ExceptionHandler를 처리합니다. API 예외 처리는 대부분 이 기능으로 해결합니다.

ResponseStatusExceptionResolver
HTTP 상태코드를 지정해줍니다.
@ResponseStatus(value=HttpStatus.NOT_FOUND)

DefaultHandlerExceptionResolver
스프링 내부 기본 예외를 처리합니다.

ResponseStatusExceptionResolver

이는 예외에 따라서 HTTP 상태 코드를 지정해주는 역할을 합니다.
@ResponseStatus가 달려있는 예외와 ResponseStatusException 예외 두 가지의 경우를 처리합니다.

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

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

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

@ReponseStatus(code=~, reason="error.bad")

처럼 쓰고 messages.properties에 다음과 같이 선언해도 됩니다. error.bad=잘못된 요청 오류입니다. 메시지 사용

두번째로 @ResponseStatusException 예외를 처리하는 과정입니다.
: @ResponseStatus는 개발자가 직접 변경할 수 없는 예외에는 적용할 수 없고 조건에 따라 동적으로 변경하는 것도 어렵습니다. 이때는 ResponseStatusException 예외를 사용하면 됩니다.

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

DefaultHandlerExceptionResolver

이는 스프링 내부에서 발생하는 예외를 해결합니다. 대표적인 TypeMismatchException은 서블릿 컨테이너까지 오류가 올라각 결과적으로 500이 반환되는데, 이는 대부분 클라이언트의 잘못된 요청때문이므로 상태코드 400이 반환되어야합니다.

코드를 사용하면 이 resolver도 마찬가지로 response.sendError()를 통해서 문제를 해결하는 것임을 확인할 수 있습니다.

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

ExceptionHandlerExceptionResolver

스프링은 API 예외 처리 문제를 해결하기 위해 @ExceptionHandler 라는 애노테이션을 사용하는 매우 편리한 예외 처리 기능을 제공하는데 이것이 바로 ExceptionHandlerExceptionResolver입니다. 스프링은 이를 기본으로 제공하고 그중 우선순위도 젤 높습니다. 그래서 실무에서 API 예외처리는 대부분 이것을 사용합니다.

해당 예외 처리를 사용하려면 @ExceptionHandler 애노테이션을 선언하고 해당 컨트롤러에서 처리하고 싶은 예외를 지정해주면 됩니다. 해당 컨트롤러에서 예외가 발생하면 이 메서드가 호출됩니다. 참고로 지정한 예외 또는 그 예외의 자식 클래스는 모두 잡을 수 있습니다.

다음 예외는 IllegalArgumentException 또는 그 하위 자식 클래스를 모두 처리할 수 있습니다.

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

@ExceptionHandler에 지정한 부모 클래스는 자식 클래스까지 처리할 수 있습니다. 자식예외가 발생하면 부모예외처리(), 자식예외처리() 둘 다 호출대상이 됩니다. 그런데 둘 중 더 자세한 것이 우선권을 가지므로 자식예외처리()가 호출됩니다. 부모 예외가 호출되면 부모예외처리()만 호출대상이 되므로 부모예외처리()가 호출됩니다.

다양한 예외

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

@ExceptionHandler에 예외를 생략하면 메서드 파라미터의 예외가 지정됩니다.

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

IllegalArgumentException 처리

@ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(IllegalArgumentException.class)
public ErrorResult illegalExHandle(IllegalArgumentException e){
	log.error("[exceptionHandler] ex", e);
    return new ErrorResult("BAD", e.getMessage());
}
  1. 컨트롤러 호출
  2. IllegalArgumentException 예외가 컨트롤러 밖으로 던져짐
  3. 예외가 발생했으므로 ExceptionResolver가 작동 (가장 우선순위 높은 ExceptionHandlerExceptionResolver)
  4. 위의 resolver는 해당 컨트롤러에 IllegalArgumentException을 처리할 수 있는 @ExceptionHandler가 있는지 확인
  5. illegalHandler()를 실행
  6. RestController이므로 HTTP 컨버터가 사용되고 응답이 JSON으로 반환된다.

UserException 처리

@ExceptionHandler
public ResponseEntity<ErrorResult> userExHandle(UserException e){
	log.error("[exceptionHandler] ex", e);
    ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
    return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
}
  1. @ExceptionHandler에 예외를지정하지 않으면 해당 메서드 파라미터 예외를 사용. 그래서 UserException을 사용
  2. ResponseEntity를 사용해서 HTTP 메시지 바디에 직접 응답(물론 HTTP 컨버터가 사용됨)
  3. ResponseEntity를 사용하면 HTTP 응답 코드를 프로그래밍해서 동적으로 변경할 수 있음.
  4. 하지만 @ResponseStatus는 애노테이션이므로 HTTP 응답 코드를 동적으로 변경할 수 없습니다.

HTML 오류화면

@Exceptional(ViewException.class)
public ModelAndView ex(ViewException e){
	return new ModelAndView("error");
}

ModelAndView를 활용해서 오류화면(HTML)을 응답하는데 사용할 수도 있습니다.

@ControllerAdvice

@ExceptionHandler를 사용해서 예외를 깔끔하게 처리할 수 있지만 정상 코드와 예외처리 코드가 하나의 컨트롤러에 섞여있습니다. 이때 @ControllerAdvice 또는 @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", "내부 오류");
}
}

@ControllerAdvice
@ControllerAdvice는 대상으로 지정한 여러 컨트롤러에 @ExceptionHandler @InitBinder기능을 부여해주는 역할을 합니다.
: @ControllerAdvice에 대상을 지정하지 않으면 모든 컨트롤러에 적용됩니다.
:@RestCOntrollerAdvice는 @ControllerAdvice와 같고 @ResponseBody가 추가되어있습니다.
(@Controller @RestController의 차이와 같습니다.)

@InitBinder는 Spring Validator 사용시 @Valid 애노테이션으로 검증이 필요한 객체를 가져오기 전에 수행할 method를 지정해주는 애노테이션입니다.

대상 컨트롤러 지정 방법

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

// 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 {}
profile
MINJU
이전 포스트

스프링 스터디 ; 검증2 Bean Validation

다음 포스트

스프링 스터디 ; 파일 업로드

0개의 댓글