웹 어플리케이션은 api 호출 시 발생하는 모든 예외를 Handling 해야 한다.
클라이언트에게 상황에 맞는 응답을 반환해주어야 하기 때문이다.
스프링 web 모듈에선 api 호출에서 발생하는 특정 예외를 catch하는 전역 핸들러를 사용할 수 있다. (@ControllerAdvice, @ExceptionHandler를 통해서 구현)
웹 어플리케이션 프로젝트에서 어떻게 예외처리를 하는게 좋을까? 어떤 기준으로 클라이언트에게 4xx, 5xx status를 반환해야 할까?
예외에는 2가지 종류가 있다고 생각한다.
- 의도된 예외(Expected Exceptions)
- 이는 애플리케이션 로직상 예상 가능한 상황에서 발생하는 예외이다.
- 재사용 가능한 커스텀 예외를 정의하고, 전역 예외 핸들러에서 catch하여 처리한다.
- 잘못된 클라이언트 입력, 데이터 검증 오류, 비즈니스 규칙 위반 등이 해당된다.
- 이러한 예외는 주로 4xx이다.
- 이러한 경우에는 커스텀 예외 클래스를 정의하여 catch하고, 적절한 HTTP 상태 코드(400 Bad Request, 409 Conflict 등)와 함께 오류 메시지를 클라이언트에 전달한다.
- 의도하지 않은 예외(Unexpected Exceptions)
- 이는 개발자가 예상하지 못한 상황에서 발생하는 예외이다.
- 다른 개발자가 의도하지 않은 경우로 사용하는 것을 방지하기 위해 사용할 수 있다.
NullPointerException,IndexOutOfBoundsException,IllegalArgumentException등- 전역 예외 핸들러에서
Exception또는RuntimeException을 catch하여 처리한다. - 500 Internal Server Error 응답을 전달한다. 이 때, 클라이언트로 필요 이상의 정보를 노출하지 않는다.
- 로그를 통해서 의도하지 않은 상황이 발생하였음을 표시한다. 또한 예외의 위치와 상황, 원인 등 적절한 문맥을 제공한다.
자바/스프링에서 제공하는 기존 예외 클래스는 의도하지 않은 예외 처리에만 사용하는 것이 바람직하다. 즉, 의도한 예외 처리는 커스텀 예외를 사용해야 한다.
의도된 예외 처리에 기존 예외를 사용하면 예외의 의미가 모호해지고, 잘못된 상황에서 발생할 수 있다.
예를 들어, 클라이언트의 잘못된 요청으로 IllegalArgumentException을 발생시키고 전역으로 catch하여 400 Bad Request를 반환한다고 가정하겠다.
이 때, DateTimeFormatter에 잘못된 인자를 넘겨주어 서버 측 문제로 에러가 발생하더라도, 별도의 try-catch 작업을 하지 않는 한, 사용자 문제가 아님에도 400 Bad Request가 발생한다.
이렇게 되면 서버 측에서도 해당 문제를 적절히 대응할 수 없다. (의도된 예외이므로 정상적인 동작이라고 판단되기 때문)
따라서 의도된 예외 처리에는 커스텀 예외 클래스를 정의하고 사용하는 것이 바람직하다.
- HTTP API 에러 응답 포멧 표준 - RFC7807, RFC9457: 예외의 응답 형식은 어떻게 해야 좋은가?
개인적인 생각이라 따로 참고한 자료는 없다.