작성일

24.10.2

작성자

조상준

개요

• 전역 예외처리를 하면서, 비즈니스 로직속의 상황에 맞게 Custom Exception을 생성하여 사용하였다. 하지만 각 상황에 맞게 디테일한 Custom Exception을 생성하다 보니까 너무 많은 종류의 예외가 생성 되었고, 너무 많은 커스텀 예외는 가독성도 떨어지고, 관리 측면에서 좋지 않다고 판단했다.

https://tecoble.techcourse.co.kr/post/2020-08-17-custom-exception/

• 결국 위의 블로그를 찾게 되었고, 위의 블로그를 참고하여 공부하였다.

0. 현재 구현 상황

• 너무 장황해서, 아래 토글에 담아 두었다. (본 기록의 목적은 문제 해결이니까..)
• 구구절절 설명한 현재 구현 상황
• 위의 현 구현 상황에 대해 설명한 이유는 결국! 표준 예외라도, HandlerMethod에서 예외 상황에 맞는 HttpStatus를 ErrorCode에 넣어준다면, 메시지 하나 만으로도 예외 상황에 대한 구분이 가능하다!
• 그래서 Custom Exception의 이름으로 예외를 굳이 표현할 필요가 없어지기 때문에,(메시지로 하면 되니까) 최대한 표준 예외를 사용하여, 가독성측면과 리소스 관리 측면에서 유리하게 리펙토링 하였다.

1. Custom Exception과 자바 표준 Exception의 사용 기준

• 자, 그렇다면 본론으로 돌아와서, 최대한 자바 표준 Exception를 사용하되, 어떤 경우에만 Custom Exception을 사용할지에 대한 명확한 기준이 필요할 것 같다.
• 기준을 잡기 전에, Custom Exception를 사용시에 얻을 수 있는 이점을 알아보자. 또한 표준 에러만 사용해도 충분한 경우도 알아보자.

먼저, 표준 에러만 사용해도 되는 경우

1. 예외에 대해 HandlerMethod에서 별도의 작업이 없고, 단순히 예외에 대한 기본정보(Http Status, Message)만 반환하는 경우에는 표준예외를 사용하자.
   • 표준 에러를 사용해도 메시지와 Http Status 코드는 나의 선택으로 설정할 수 있다.
   • 단, 메시지는 구체적인 상황마다 설정 가능하지만, Http Status 코드는 HandlerMethod에서 작성하기 때문에, 해당 예외 발생시에는 동일한 코드가 생성된다. (DuplicateKeyException → 409 Conflict로 설정했기 때문에, 모든 DuplicateKeyException 발생시에는 응답으로 409 코드가 나간다.)
   • 물론, 위의 이유 때문에 Http Status 코드 설정이 완전히 자유롭지는 않지만, 동일한 예외를 사용하는 경우에 다른 Http Status를 반환하는 경우는 거의 없다고 판단하였고, 그렇기 때문에 메시지만으로도 충분히 상황 구분 가능하다.

• 이로 인한 부수적인 이점은 다음과 같다.
  1. 표준 예외를 사용하면, 가독성이 높아진다.
     1. 이미 익숙하고, 쓰임이 있는 표준이기 때문에 가독성이 올라간다.
     2. 그와 반대로, Custom Exception의 경우, 해당 예외의 쓰임에 대해 해석하는 과정이 필요하기 때문에 가독성이 좋지 않다.
  2. 모든 상황에 Exception을 만들지 않아, 관리할 클래스가 줄어든다.
     1. 중복적이고, 모든 상황 작은 단위로 구분해둔 클래스가 많아지면, 관리하기 어렵다.

자, 그럼 Custom Exception은 어느 상황에 필요할까?

• 장점1: 물론, 이름만으로 정보 전달이 가능한 점은 매우 좋다.
  • 하지만 메시지만으로도 상황 정보는 충분한데, 굳이 사용해서 관리할 리소스가 많아진다는 것은 더 치명적인 단점 같다.
• 장점2: 상세한 예외 정보를 제공할 수 있다.
  • Http Status, Message 뿐 아니라, 구체적으로 어떤 인덱스,키,등 어디에서 예외가 발생했는지 알려주는 상황에서는 Custom Exception이 필요하다.