개발자
안녕하세요, 현재 서비스를 만들고 있는 상태입니다, 저번 서비스 보다는 더욱 유지보수를 올리고 어느정도 규약이 지켜진 상태로 만들고 싶은 상태인데, 점점 규모가 커지다보니 적절한 예외가 필요하다 느꼈고 예외처리를 세분화(MemberException, AuthException 등..) 시키는 과정에서 코드 중복이 상당히 많이 발생하는 문제가 생겼습니다, 그래서 모든 예외처리 로직을 common쪽으로 이동시키고 인터페이스를 통해서 느슨하게 연결을 해둔 상태인데, 이 방법이 괜찮을지 현업 분들의 조언을 듣고 싶습니다, 다소 부족한 설명임에도 불구하고 답변을 주신다면 감사하겠습니다. 오늘도 좋은 하루 되시길 바랍니다!
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2024년 07월 02일
예외 처리를 중앙화하고 개별 예외를 세분화하는 접근법은 매우 좋습니다. 이러한 방식을 사용하면 코드의 유지보수성이 향상되고, 오류 발생 시 디버깅이 더 쉬워집니다. 다음과 같은 일반적인 팁들이 도움이 될 수 있습니다. 1. 최상위 예외 클래스: 모든 특정 예외가 상속받을 최상위 예외 클래스를 만드세요. 이 클래스는 애플리케이션의 기본 예외 정보(예: 에러 메시지, 에러 코드 등)를 정의합니다. 2. 구체적인 하위 예외 클래스: 필요에 따라 구체적인 하위 예외 클래스(MemberException, AuthException 등)를 만드세요. 3. 중앙에서 예외 처리하기: 이 방식의 주요 아이디어는 중앙에서 모든 종류의 예외를 잡아내고 관련된 작업(로그 등록, 에러 메시지 포맷 수정 등)을 처리하는 것입니다. 4. 인터페이스 vs 추상 클래스: 모듈간 느슨한 연결 및 공통 로직 분리에 대해 고민하신다면, 인터페이스보다 추상 클래스가 나을 수도 있습니다. 인터페이스는 여러 구현에 거쳐 동일한 메소드 시그니처를 강제하기 때문에 코드 중복이 발생할 수 있습니다. 반면, 추상 클래스는 공통적인 로직을 한곳에서 관리하고 하위 클래스에서만 차이가 나는 로직을 구현할 수 있어 유연성과 중복 코드 제거를 동시에 달성할 수 있습니다. 5. 예외를 향후 사용하기: 더 나아가, 예외는 단순히 오류를 알리는 도구가 아니라 코드의 일부로서 값을 전달하는 방식으로 사용될 수도 있습니다. 이렇게 사용함으로써 서비스 논리와 예외 처리 부분의 효율성을 높일 수 있습니다. 다들 사례마다 적합한 접근법이 다르므로, 개발 환경과 요구사항에 따라 알맞은 방법을 선택하시길 바랍니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!