사용자 정의 예외 클래스는 어떤 패키지에서 관리하는 게 좋을까?

ljinsk3·2020년 5월 26일
0

Spring / Spring Boot

목록 보기
7/7
post-thumbnail

웹 어플리케이션을 개발 하다보면 사용자 정의 예외를 별도로 정의하는 경우가 많이 생긴다. 상황에 따라, 개발자에 따라 다르긴하겠지만 모든 예외를 사용자 정의 예외로 관리하는 경우도 있는데, 이렇게 사용자 정의 예외 클래스가 많아질 경우 어디서 관리하는게 좋은지에 대해 고민해보자.

다음은 지하철 경로조회 프로그램을 만들면서 내가 실제로 정의했던 예외들이다.

전체적으로 모든 예외를 한곳에서 처리할 수 있는 ExceptionAdvice가 controller 패키지에 있어야 한다고 생각했고,예외 응답을 내려줄 수 있는 ExceptionResponse 그리고 Advice에서 다루는 사용자 정의 예외 클래스들도 같은 레벨에 만들게 되었다.

어떤게 컨트롤러이고 어떤게 예외 클래스 인지 한눈에 구별이 쉽지 않다는 문제가 보인다. 그리고 web 뿐만아니라, service 패키지에도 사용자 정의 예외가 곳곳에 흩어져있다.

만약 사용자 정의 예외가 더 추가된다면 어떻게 될까? 그렇게 되면 이게 controller 패키지인지 exception 패키지인지 분간이 안갈 정도로 암담한 상황이 될 것이다.

많은 개발자들은 아마 이러한 문제점들을 방지하기 위해서 exception 이라는 상위 패키지를 따로 분리해서 관리하고 있을 것이다. 나 역시도 처음 리팩토링 할 때는 하나의 패키지에 사용자 정의 클래스들을 몰아서 관리했었다.

하지만 이에 대한 문제점도 존재한다. 예외 클래스에 대한 이름을 명확하게 잘 짓는다면 문제가 덜할 수 도 있지만, NotExisted~, Existed~, Invalid~ 등의 비슷한 접두어를 가지고 이름을 짓기 때문에 이름만봐서는 어떤 기능을 실행할 때 발생하는 예외인지 가늠하기 쉽지 않았다.

그래서 궁금했다. 예외 클래스의 이름을 잘 짓는 방법이 있을까? 수많은 사용자 정의 클래스들을 잘 관리하는 방법이 존재할까?

다른 개발자들은 exception 클래스를 어떻게 관리하고 있는지 궁금하여 검색을 해보았다. 스택오버 플로우에 나와 같은 고민이 담긴 질문들이 몇몇 눈에 보였다.

예외 클래스들을 별도로 패키징을 하여 관리하는게 좋은 방법인지에 대한 질문들이었다. 답변들은 대체로 다음과 같은 내용이 담겨있었다.

  • 별도의 패키징은 패키지들 간에 불필요한 종속성을 만들어낼 수 있다.
  • 사용자 정의 예외 클래스는 해당 예외를 발생시킬 수 있는 클래스와 동일한 패키지에 정의해야 한다.
  • 사용자 정의 예외는 웹 어플리케이션 전체에 걸쳐서 범용적으로 쓰이는 것이아니라 특정 섹션에 중점을 두어야 한다.
  • 패키지는 하나의 기능을 수행할 수 있어야 한다. 사용자 정의 예외는 기능 단위의 일부이며 그 기능을 수행하는 패키지와 동일한 위치에 있어야 한다.
  • 패키지는 일관성, 응집성이 있어야 한다. 서로 관련없는 예외 클래스를 모아놓는 건 bad practice에 해당한다.

처음에는 대답들을 듣고 놀랐지만 그 이유를 들으니 납득이 되었다.

예외 클래스 패키지를 별도로 관리하는 것이아닌 예외를 발생시키는 기능단위 패키지에 존재하도록 만든다.

위 답변을 기준으로 나의 번잡한 사용자 정의 클래스들의 위치를 리팩토링해보았다.

예외가 실제로 발생하는, 직접적으로 연관되어있는 service단으로 클래스의 위치를 옮겼고, web 패키지 아래에 advice 패키지를 추가하여 common exception 과 관련된 부분을 exception이라는 패키지로 모아두었다. (이 부분은 util의 성질을 띄는 공통적으로 사용하는 부분이라 괜찮다고 생각)

예외를 하나의 exception 패키지로 몰아서 처리하는 것보다 훨씬 가독성이 좋아진 것 같다.
덕분에 패키지라는게 어떤 레벨로 분류가 되고, 역할을 하는지 조금 더 명확해졌다.

0개의 댓글