검사 예외의 단점
검사 예외를 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 결과를 코드로 반환하거나 비검사 예외를 던지는 것과는 달리, 검사 예외는 발생한 문제를 프로그래머가 처리해 안정성을 높이게끔 해주기 때문이다. 물론, 검사예외를 과하게 사용한다면 오히려 쓰기 불편한 API가 된다.
어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드에서는 catch블록을 이용해 그 예외를 붙잡아 처리하거나, 더 바깥으로 던져 문제를 전파해야만 한다. 이 방식은 어느 쪽이든 API 사용자에게 부담을 준다. 더구나 검사 예외를 호출하는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 부담이 더욱 커졌다.
만약 이미 다른 검사 예외를 던지는 상황에서 또 다른 검사 예외를 추가하는 경우라면 catch 문 하나를 추가하면 되지만, 검사 예외가 단 하나 뿐이라면 오직 그 하나의 예외 때문에 try블록을 추가해야 하고 스트림에서 직접 사용하지 못하게 된다. 따라서 검사 예외를 던지지 않는 방법이 없는지 고민을 해봐야 한다.
검사 예외를 회피하는 방법
검사 예외를 회피하는 가장 쉬운 방법은 적절한 결과 타입을 담은 옵셔널을 반환하는 것이다. 검사 예외를 던지는 것 대신 빈 옵셔널을 반환한다. 하지만 이 방식은 예외의 부가정보를 담을 수 없다는 단점이 있다.
반면, 예외를 사용하게 되면 구체적인 예외 타입과 그 타입이 제공하는 메서드들을 활용해서 부가 정보를 제공할 수 있다.[아이템 70]
또 다른 방법으로는, 검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 바꿀 수 있다. 첫 번째 메서드는 예외가 던져질지 여부를 boolean 값으로 반환한다. 하지만 boolean 으로 검증을 하고 메서드를 호출하는 사이에 다른 스레드에 의해서 객체의 상태가 변할 수 있기 때문에 이 방법도 적절하지 않을 수 있다.
정리
검사 예외는 꼭 필요한 곳에서만 사용하면 프로그램의 안정성을 높여주지만, 남용하면 쓰기 힘든 API를 낳는다. API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자.
복구가 가능하며, 호출자가 그 처리를 해주기를 바란다면, 우선 옵셔널을 반환해도 될지 고민하자. 옵셔널 만으로는 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.
