일화

초청을 받아 설계 악취 강의를 할 때 참석자 중 한 명이 아주 특이한 문제를 보고했다. 그는 대규모 자바 프로젝트에 컨설턴트 아키텍트로 참여했는데, 프로젝트 팀이 다음 문제를 디버깅하는 데 많은 시간을 소비해 왔다는 사실을 발견했다.

외부 라이브러리에서 메서드를 호출하면 MissingResourceException 예외가 가끔 던져졌다. 팀원 중 한 명은 이 예외를 처리하려고 catch 처리기를 추가했고, 로깅 라이브러리를 사용하여 예외를 로그로 남겼다. 하지만 catch 처리기를 추가한 후에도 팀을 짜증나게 하는 상황이 발생했으며, 애플리케이션은 종종 동일 예외와 함께 충돌을 일으켰다.

이 참석자는 로깅 코드를 제거하고 스택 추적을 콘솔에 뿌리도록 제안했고, 수정이 끝난 후 애플리케이션을 반복 실행했다. 결국 충돌이 다시 한 번 일어났을 때 던져진 예외는 코드가 처리하던 java.util.MissingResourceException이 아니라 외부 라이브러리의 패키지에 정의한 사용자 정의 예외인 MissingResourceException이라는 사실이 밝혀졌다. 이런 예외는 RuntimeExceptions이므로, 컴파일러는 예외를 잡기 위한 catch 블록에 대해 어떤 오류도 일으키지 않았고, 해당 코드 블록에서 결코 예외를 잡을 수 없었다.

비록 이것은 프로그래밍 실수처럼 보이지만, 더 깊숙이 들여다보면 설계 문제 때문임을 알 수 있다. 설계 명세는 명시적으로 처리해야 하는 예외 유형을 명확하게 언급하지 않았다. 두 예외 클래스의 동일한 이름과 결합하여 이런 문제는 프로그래머가 잘못된 예외를 처리하게 만들었다.

이 일화를 보면 API를 설계할 때는 많은 주의를 기울여야 함을 알 수 있다. 여기서는 외부 API에 정의된 예외 이름이 기존 JDK 예외와 충돌했기 때문에 외부 API의 클라이언트에 문제를 초래한 것이다.

이 일화에서는 다음 두 가지 통찰력을 얻을 수 있다.

• 설계 문제는 찾기 어려운 결함을 초래할 수 있다.

• 작명이 중요하다. 특히 중복된 이름은 피하자!