⚓️서론

이 장은 짧은 내용이다. 제목이 처음이자 끝이라고 생각한다.

짧은 내용이지만 제목을 반복해서 머리에 각인 시키는 연습을 하자.

내용이 짧은 만큼 서론을 마치고 바로 본론으로 들어가겠다.

➡️API 설계자의 목소리를 흘려듣지 말자.

• 에외를 무시하기란 아주 쉽다.

//catch 블록을 비워두면 예외가 무시된다. 아주 의심스러운 코드다.!
try{
    ...
}catch(SomeException e){
}

위와 같이 catch 블록을 비워두면 예외가 무시하게된다.

본래 예외는 문제 상황에 잘 대처하기 위해 존재한다. 하지만 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 블록으로 못 본 척 지나치면 그 프로그램은 오류를 내재한 체 동작하게 된다. → 어느 순간 문제의 원인과 아무 상관없는 곳에서 갑자기 죽어버릴 수도 있다.
• 예외를 적절히 처리하면 오류를 완전히 피할 수 있다.
• 무시하지 않고 바깥으로 전파되기멘 놔둬도 최소한 디버깅 정보를 남긴 채 프로그램이 신속히 중단되게는 할 수 있다.