예외 처리

현재 이 서비스에서 발생할 수 있는 이유는 다음과 같다.

• 시큐리티 계층

401 요청의 인증 여부: AT 검증 실패, RT 검증 실패, ...?

403 요청의 인가 여부: 일단 v2까지 발생할 일 진짜 거의 없음.

• 컨트롤러 계층

400 요청의 온전성?: 대부분 정해져 있으며, 외부로는 굳이 세부적으로 나눌 이유 없음. 로그만 잘하자

405 요청 메소드의 지원 여부: YES or NO만이 중요하다. 나눌 필요 없

422 요청 필드가 검증 결과 유효한 값을 가졌는지: 나눠야 됨...

413 요청 본문의 파일 형식을 지원하는 지: YES or NO만이 중요하다. 나눌 필요 없

415 요청 본문의 파일이 제한 범위 이내인지: YES or NO만이 중요하다. 나눌 필요 없

429 요청이 Rate Limit을 넘지 않았는지: YES or NO만이 중요하다. 나눌 필요 없

• 서비스 계층

404 리소스의 존재성: 나눠야 됨

409 요청의 내용과 서버의 상태가 충돌하는 지: 나눠야 됨

500 서버 오류: 이것도 내부 로깅은 잘해야 함

502 외부 API 오류 (그 외)

503 내부 API 오류 (AI 서버)

예외 클래스 구조 구성 (+ messageSource 연결)

base class

messageSource 관련 설정

2단계

HTTP 상태 코드별 분기 적용, 기본 메세지 작성, 상태 코드 별 ProblemDetail 형식 정의

기본 형식

{
  "trace_id": String,
  "code": String,
  "type": URI,
  "title": String,
  "instance": URI,
}

3단계

상태 코드에서 더 세부적으로 분기가 필요한 본문들

• 401, 404, 409, 502?는 세부적으로 나눌 필요가 있음

422

{
  "trace_id": String,
  "code": String,
  "type": URI,
  "title": String,
  "instance": URI,
  "errors": [
    {
      "code": "String",
      "detail": String,
      "pointer": JSON Pointer
    },
    ...
  ]
}

1. @Valid @RequestBody 단독 -> MethodArgumentNotValidException (메소드 파라미터에 대한 직접적인 유효성 검증이 발생하지 않았을 경우)
2. 나머지 (어떠한 경우던 간에 @NotNull, @Positive 등 메소드 파라미터에 유효성 검증 어노테이션에 의한 직접적인 유효성 검증이 발생한 경우) -> HandlerMethodValidationException

• 흐름

  1. HandlerMethodValidationException

     • HandlerMethodValidationException.getParameterValidationResults().methodParameter.parameterName(본문이 아닌 경우 = result.type = ParameterValidationResult) 또는 HandlerMethodValidationException.getParameterValidationResults().fieldErrors.field(본문인 경우 = result.type = ParameterErrors)에서 필드 이름을 추출해 오류 코드를 매핑 -> code, detail, pointer

     • 파라미터 유효성 검증용 messageSource에 각 코드별 detail 필요

       • 이 누락을 컴파일 예외로 예방한다면?
       • pointer는 field가 전체 경로를 가지기 때문에, 그대로 쓰거나 조금 변형하면 될듯

     • FieldErrors에서는 field가 전체 경로를 가지기 때문에, 매핑 시 split(".") 등으로 슬라이싱이 필요할 듯

  2. MethodArgumentNotValidException

     • getFieldErrors로 필드별 오류에 접근할 수 있다고 함

• 구현

  • @RestControllerAdvice

    • @ExceptionHandling(HandlerMethodValidationException.class), @ExceptionHandling(MethodArgumentNotValidException.class)
    • 필드 이름과 오류 코드를 매핑
    • FieldErrors의 각 필드 오류를 code, detail, pointer를 가진 DTO로 매핑하여 errors 컬렉션으로 변환
    • errors를 담은 422 오류로 변환

  • message.properties

    • 오류 코드에 대응하는 detail 작성

TO-BE

3단계 예외

예외 클래스: 2단계 예외 extend, 예외 별 code 선언

message.properties: 오류의 type, title만 선언

2단계 예외

각 상태 코드 별 fallback용 code, type, title 선언

base class

code를 이용해 message.properties에서 오류에 해당하는 type, title 조회, ProblemDetail 생성

• getTypeMessageCode(), getTitleMessageCode()

new ErrorResponseException(status, body, cause, messageDetailCode, null)