• 전체적으로 예외 처리 응답은 InvalidParameter를 제외하고, 단순히 메시지와 status code, code만 조합하여 반환하는데, code란 사람이 알아볼 수 있는 간단한 카테고리의 개념이다.
  • InvalidParameter는 내부적으로 list형태로 만들어 dto로 반환함.
• 변경 사항
  • DTO 반환 클래스들을 굳이 더 만들지 않고, 하나로 관리하기 위해 InvalidParameters 키 값에 빈 배열을 넣음.

• 고민사항 : unchecked exception에 대해 항상 동일한 스키마로 응답하기 위해 예외처리를 어떻게 할 지
  • 에러에 대한 응답 메시지를 통일화, 내부적으로는 로깅만 함.
• ExceptionPolicy, BusinessExceptionPolicy 인터페이스를 선언한 이유
  • 에러 응답 스키마를 통일
  • 추후 확장 가능성을 위해 열어둠 : ApplicationException과 같은 unchecked 예외
  • ApplicationException이 일어날 수 있는 경우
    • timeout, 데이터베이스 커넥션 에러 등등..

웹 애플리케이션 서버에서 만날 수 있는 예외 상황은 무엇이 있을까

• 웹 MVC에서 일어날 수 있는 예외 : 사용자가 굳이 커스텀하지 않아도 웹 mvc에서 미리 구현한 예외 클래스가 있다. 이외에도 많지만 대표적인 것들만 적었다.
  • @valid로 걸어놓은 dto의 유효성 검사에서 실패 → handleMethodArgumentNotValid
  • 지원하는 method가 없음 → handleHttpRequestMethodNotSupported
  • Path Variable이 없거나 할당 실패 → handleMissingPathVariable
  • request parameter가 없거나 할당 실패 → handleMissingServletRequestParameter
  • 메시지 컨버터에서 변환할 수 없음 → handleHttpMessageNotReadable

ResponseEntityExceptionHandler에 대하여

문제상황

에러가 났는데 내가 문젠지 호출자가 문젠지 알 수가 없는 상황이면 결국 물어물어 누가 범인인지 찾아야 하기 때문에 생산성이 떨어진다. 따라서 어떤게 문젠지 상세히 알려주어야 한다.

클라이언트 서버 구조에서 에러 상황은 다양하다. 대표적으로 parameter가 비어있거나, 유효하지 않을 때, 지원하지 않는 http method일 때가 있다.

이러한 상황을 spring webmvc나 서블릿에서 클래스로 미리 정의해놓은게 있다.

그런데 문제가 있는데, 비즈니스 에러일 때는 클래스를 각 상황마다 선언해주어야 한다.

1. e.g.) 찾으려는 객체가 없거나 진행할 수 없는 상황일 때

이렇게 되면 클래스 양이 많아짐에 따라 유지보수도 어려워진다.

따라서 이를 통일하기 위해 상속과 확장의 개념을 사용한다.

내가 참고한 사이트는 https://medium.com/@georgeberar.contact/springboot-standardized-api-exception-handling-f31510861350 이다.

먼저 예외가 발생했을 때 어떤 것을 클라이언트에게 보여줄 지 정해야 한다. 이를 위해 ExceptionPolicy 인터페이스를 만들고 코드와 메시지를 전달하도록 한다.

public interface ExceptionPolicy {
  String getCode();
  String getMessage();
}

여기서 코드란 HttpStatus 상태 코드가 아니라 비즈니스적으로 유의미한 코드이다.