기존 프로젝트의 코드에서 예외 처리에 대한 문제점을 찾아 수정하고 느낀점을 적은 글 입니다.

아래는 이전 코드의 사진입니다.

수정 이전의 @RestControllerAdvice 클래스의 Handler 사진. 도메인별로 관리를 따로하고 있음

수정 이전의 Service Layer 의 검증, 엔티티 삭제 로직의 사진

위 두 모습을 보면서, 다음의 문제를 느꼈습니다.

1. 공통된 관심사인 예외와 로깅이 분리되어 있음
   1. 로깅 코드의 경우 반복되기 때문에 메서드화 하는게 좋음
   2. 예외에 필요한 message 상수화가 필요함
2. Advice 용도의 클래스가 규모가 커지고 예외가 늘어나면 관리포인트가 증가할것 같음
3. 테스트 코드 작성이 어려움
   1. 예외에 따른 일관된 message 가 필요
4. Optional 클래스의 orElseThrow(Supplier<? extends X> exceptionSupplier) 를 일관성있게 사용하지 못함

스프링 Controller 를 통해 받을수 있는 여러 데이터와 검증등의 어노테이션에서는 여러 예외가 발생하고, 여러 메서드의 호출이나 DB조회시 예외가 발생할 소지가 존재합니다. 이러한 예외는 명확한 기준을 세우고 처리 해야하며, 분명한 테스트가 동반되어야 합니다.