아이템 71. 필요 없는 검사 예외 사용은 피하라. - ksw6169/effective-java GitHub Wiki

검사 예외를 남용하면 쓰기 불편한 API를 낳는다.

• 검사 예외를 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리 검사 예외는 발생한 문제를 프로그래머가 처리하여 안전성을 높이게끔 해주기 때문이다.
• 물론 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 된다. 어떤 메소드가 검사 예외를 던지겠다고 선언했다면 이를 호출하는 코드에서는 직접 처리하거나 더 바깥으로 던져야 하기 때문이다. 더구나 검사 예외를 던지는 메소드는 스트림 안에서 직접 사용할 수 없기 때문에 자바 8부터는 부담이 더욱 커졌다.
• API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우라면 이 정도 부담은 괜찮을 것이다. 하지만 둘 중 어디에도 해당되지 않는다면 비검사 예외를 사용하는 것이 좋다.

검사 예외를 회피하는 방법

1. 적절한 결과 타입을 담은 옵셔널을 반환한다.

• 검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환한다.
• 이 방식의 단점은 예외가 발생한 이유를 알려주는 부가 정보를 담을 수 없다는 것이다.

2. 검사 예외를 던지는 메소드를 2개로 쪼개 비검사 예외로 바꾼다.

• 다음은 리팩토링 전 코드로 검사 예외를 던진다.

try {
    obj.action(args);
} catch (TheCheckedException e) {
    ...  // 예외 상황에 대처한다.
}

• 이를 상태 검사 메소드와 비검사 예외를 던지는 메소드로 리팩토링하면 다음과 같다.

if (obj.actionPermitted(args)) {
    obj.action(args);
} else {
    ...  // 예외 상황에 대처한다.
}

• 이 리팩토링을 모든 상황에 적용할 수는 없지만 적용할 수만 있다면 더 쓰기 편한 API를 제공할 수 있다.

핵심 정리

• 꼭 필요한 곳에 사용한다면 검사 예외는 프로그램의 안전성을 높여주지만 남용하면 쓰기 고통스러운 API를 낳는다.
• API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자.
• 복구가 가능하고 호출자가 그 처리를 해주길 바란다면 우선 옵셔널을 반환해도 될지 고민하자.
• 옵셔널만으로는 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.

참고 자료

• Effective Java 3/E