아이템[77]. 예외를 무시하지 마라

API 설계자가 메서드 선언에 예외를 명시하는 까닭은, 그 메서드를 사용할 때 적절한 조치를 취해달라고 말하는 것입니다.

API 설계자의 목소리를 흘려버리지 맙시다.

안타깝게도 예외를 무시하기란 아주 쉽습니다.

해당 메서드 호출을 try 문으로 감싼 후 catch 블록에서 아무 일도 하지 않으면 끝입니다.

// catch 블록을 비워두면 예외가 무시된다.
try {
    ...
} catch (SomeException e) {
}

예외는 문제 상황에 잘 대처하기 위해 존재하는데 catch 블록을 비워두면 예외가 존재할 이유가 없어집니다.

비유하자면 화재경보를 무시하는 수준을 넘어 아예 꺼버려, 다른 누구도 화재가 발생했음을 알지 못하게 하는 것과 같습니다.

운이 좋아 별 탈이 없으면 다행이지만 끔찍한 참사로 이어질 수도 있으니, 빈 catch 블록을 목격한다면 꼭 좌시하시면 안 됩니다.

물론 예외를 무시해아 할 때도 있습니다.

예를 들어 FileInputStream을 닫을 때가 그렇습니다.

(입력 전용 스트림이므로) 파일의 상태를 변경하지 않았으니 복구할 것이 없으며,

(스트림을 닫는다는 건) 필요한 정보는 이미 다 읽었다는 뜻이니 남은 작업을 중단할 이유도 없습니다.

혹시나 같은 예외가 자주 발생한다면 조사해보는 것이 좋을 테니 파일을 닫지 못했다는 사실을 로그로 남기는 것도 좋은 생각입니다.

어쨌든 예외를 무시하기로 했다면 catch 블록 안에 그렇게 결정한 이유를 주석으로 남기고 예외 변수의 이름도 ignored로 바꿔놓도록 합시다.

Future<Integer> f = exec.submit(planarMap::chromaticNumber);
int numColors = 4; // 기본값. 어떤 지도라도 이 값이면 충분하다.
try {
    numColors = f.get(1L, TimeUnit.SECONDS);
} catch (TimeoutException | ExecutionException ignored) {
    // 기본값을 사용한다(색상 수를 최소화하면 좋지만, 필수는 안디ㅏ).
}

이번 아이템의 내용은 검사와 비검사 예외에 똑같이 적용됩니다.

예측할 수 있는 예외 상황이든 프로그래밍 오류든, 빈 catch 블록으로 못 본 척 지나치면 그 프로그램은 오류를 내제한 채 동작하게 됩니다.

그러다 어느 순간 문제의 원인과 아무 상관없는 곳에서 갑자기 죽어버릴 수도 있습니다.

예외를 적절히 처리하면 오류를 완전히 피할 수도 있습니다.

무시하지 않고 바깥으로 전파되게만 놔둬도 최소한 디버깅 정보를 남긴 채 프로그램이 신속히 중단되게는 할 수 있습니다.