모듈간 예외 처리 전략

 

 

모듈화 된 시스템은 각 모듈이 독립적으로 기능을 수행할 수 있도록 만들어 준다. 그리고 각 모듈에서 발생하는 예외는 어떻게 관리하고 전달할지에 대한 고민이 필요하다.

 

 

 

 

평소에 예외 처리 전략을 공통으로 발생하는 예외와 모듈에서 발생할 수 있는 예외 이렇게 구분해서 사용하고 있었다. 아래 영상을 보면서

 

 

"모듈로 구성할 때, 해당 모듈에서 발행하는 예외는 그 모듈 내에 두어야 한다."

 

를 알게 되었다. 

 

https://www.youtube.com/watch?v=bjaiaEEllMI

 

 

 

 

 

모듈화 된 시스템의 원칙 중 하나는 모듈은 스스로 독립적일 수 있어야 한다.

 

 

 

 

즉, 모듈은 다른 시스템에 의존하지 않고, 독립적으로 기능을 수행할 수 있어야 한다.

 

 

 

 

 

그래서 예외 처리할 때는 모듈에서 발생하는 예외는 그 모듈 내에서 처리해야 한다. 해당 모듈 예외를 공통 예외 클래스로 빼서 전역으로 처리하는 방식은 모듈화의 장점을 해칠 수 있다.

 

 

 

 

모듈 하나를 떠서 다른 프로젝트에 옮겼을 때 그대로 사용할 수 있게 해야 한다.

 

 

 

 

 

 

 

아래 예시처럼 ExampleClient의 관련된 예외는 ExampleClientException에서 처리하고 모듈로 사용할 수 있도록 했다.

 

 

 

 

 

 

그리고 FeignClientException 예외가 발생하면 자기 모듈의 예외인 ExampleClientException으로 감싸서 예외처리를 했다.

 

 

 

 

모듈이 예외를 사용하는 쪽에 제대로 전달할 수 있도록 구성하고, 사용하는 쪽에서는 해당 모듈이 발생시킨 예외를 어디까지 전달할지에 대한 규칙을 고민해야 한다.

 

 

 

1) 프레젠테이션 레벨에서의 예외처리(Controller)

 

일반적으로 프레젠테이션 레벨을 담당하는 Controller에서는 예외처리를 가장 먼저 해야 한다.

 

 

클라이언트에서 전달한 요청값이 유효한지 확인

    요청값이 정상 -> 요청값이 온전히 가공된 상태로 비즈니스 레이어로 전달

    요청값이 비정상 -> 예외 발생

 

 

 

 

2) 비즈니스 레이어에서의 예외처리(Service)

- 비즈니스 레이어에서 발생해도 되는 예외인지 판단 (예외가 발생하는 이유를 비즈니스 관점에서 판단)

 

예) point사용 메서드 -> 포인트 부족 예외 O, 유저정보업데이트 메서드 -> 유저를 못 찾음 예외 O

 

 

 

 

 

[결론]

각 모듈은 자신에게 해당하는 예외를 정의하고, 그 예외를 내부에서 처리하는 방식으로 독립성을 유지해야 한다.