검사 예외는 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 검사 예외는 발생한 문제를 프로그래머가 처리하여 안전성을 높이게끔 해준다.
그러나 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 된다. 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야만 하므로 API 사용자에게 부담을 준다. 더구나 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바 8부터는 부담이 더욱 커졌다.
API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미있는 조치를 취할 수 있는 경우라면 검사 예외의 부담쯤은 받아들일 수 있을 것이다.
그러나 둘 중 어디에도 해당하지 않는다면 비검사 예외를 사용하는 것이 좋다.
검사 예외를 회피하는 가장 쉬운 방법은 적절한 결과 타입을 담은 옵셔널을 반환하는 것이다. 검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환하면 된다.
또 다른 방법은 검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 바꾸는 것이다. 첫 번째 메서드는 예외가 던져질지 여부를 boolean 값으로 반환하는 상태 검사 메서드다. 다음의 예시를 보자.
if (obj.actionPermitted(args)) { // 상태 검사
obj.action(args);
} else {
... // 예외 상황에 대처한다.
}단, 상태 검사 메서드는 아이템 69에서 말했듯이, 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인에 의해 상태가 변할 수 있다면 적절하지 않다.
또한, actionPermitted가 action 메서드의 작업 일부를 중복 수행한다면 성능에서 손해이다.
📌 핵심 정리
꼭 필요한 곳에만 사용한다면 검사 예외는 프로그램의 안전성을 높여주지만, 남용하면 쓰기 고통스러운 API를 낳는다.
API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자.
복구가 가능하고 호출자가 그 처리를 해주길 바란다면, 우선 옵셔널을 반환해도 될지 고민하자. 옵셔널만으로는 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.
