API 설계자가 메서드 선언에 예외를 명시하는 이유는 적절한 조치가 필요하기 때문인데 많은 개발자들이 API 설계자의 목소리를 흘려버리고 있습니다.
- 아래 코드처럼 try문으로 감싼 뒤 catch 블록에서 아무 일도 하지 않는 코드들이 많음
코드 문제점
- 예외는 문제 상황에 잘 대처하기 위해 존재하는데 catch 블록을 비워두면 예외가 존재할 이유가 없어짐
- 운이 좋아 코드가 잘 돌아갈 수도 있지만, 적절한 예외 처리가 이루어지지 않으면 오동작할 가능성이 높아짐
- 따라서 빈 catch 블록은 절대적으로 피해야 함
- 예측할 수 있는 예외 상황이든 프로그래밍 오류든, 빈 catch 블록으로 못 본 척 지나치면 해당 프로그램은 오류를 내재한 채 동작
- 그러다 어느 순간 문제의 원인과 아무 상관없는 곳에서 갑자기 죽어버릴 수 있음
- 예외를 적절히 처리했다면 오류를 완전히 피할 수도 있으므로 예외를 무시하지 않고 바깥으로 전파하게만 놔둬도 최소한 디버깅 정보를 남긴 채 프로그램을 신속히 중단시킬 수 있음
예외를 무시해도 되는 케이스
- FileInputStream을 닫을 때는 예외를 무시해도 무방
- 입력 전용 스트림이기 때문에 파일의 상태를 변경하지 않았으니 복구할 것이 없으며, 스트림을 닫는다는 것은 필요한 정보는 이미 다 읽었다는 뜻이니 남은 작업을 중단할 이유가 없음
- 혹여나 같은 예외가 자주 발생한다면 조사해 보는 것이 좋을 테니 파일을 닫지 못했다는 사실을 로그로 남기는 것도 좋은 생각
- 어쨌든 예외를 무시하기로 했다면 catch 블록 내 그렇게 결정한 이유를 주석으로 남기고 예외 변수의 이름도 ignored로 바꾸는 것을 권장
참고
이펙티브 자바
반응형
'JAVA > Effective Java' 카테고리의 다른 글
[아이템 79] 과도한 동기화는 피하라 (0) | 2024.04.07 |
---|---|
[아이템 78] 공유 중인 가변 데이터는 동기화해 사용하라 (0) | 2024.03.29 |
[아이템 76] 가능한 한 실패 원자적으로 만들라 (0) | 2024.03.29 |
[아이템 75] 예외의 상세 메시지에 실패 관련 정보를 담으라 (0) | 2024.03.29 |
[아이템 74] 메서드가 던지는 모든 예외를 문서화하라 (0) | 2024.03.28 |