Item71 - 필요 없는 검사 예외 사용은 피하라

필요 없는 검사 예외 사용은 피하라

검사 예외를 싫어하는 자바 프로그래머가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다.

1️⃣  검사 예외를 과하게 사용하면 쓰기 불편한 API가 된다.

• 검사 예외는 호출자가 처리해야하는 강제성을 지니기 때문에 부담을 주게 된다.

• 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바 8부터는 그 부담이 더욱 커졌다.

• 특히 메서드가 단 하나의 검사 예외만 던질 때 부담이 크다.
• 그 예외 하나 때문에 API 사용자는 try 블록을 추가하고 스트림에서 사용하지 못하기 때문이다.

대안

1️⃣  옵셔널을 반환하라.

• 검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환하면 된다.

• 이 방식의 단점이라면 예외가 발생한 이유를 알려주는 부가 정보를 담을 수 없다는 것이다.

• 반면 예외를 사용하면 구체적인 예외 타입과 그 타입이 제공하는 메서드들을 활용해 부가 정보를 제공할 수 있다.

2️⃣  메서드를 2개로 쪼개 비검사 예외로 바꾸자.

• 검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 바꿀 수 있다. 이 방식에서 첫번째 메서드는 예외가 던져질지 여부를 boolean 값으로 반환한다.

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

// 리팩터링 한다면?

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

• 모든 상황에서 이 리팩터링을 할 수 있는 것은 아님

• 또한 상태 검사 메서드의 단점도 그대로 적용된다.
• 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인에 의해 상태가 변할 수 있다면 이 리팩터링은 적절하지 못하다.
• 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 중복 수행한다면 성능적으로 손해이므로, 이 리팩터링이 적절하지 않을 수 있다.

결론

• 꼭 필요한 곳에만 사용한다면 검사 예외는 프로그램의 안정성은 올려주지만, 남용하면 쓰기 고통스러운 API를 낳는다.

• API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지도록 하자.

• 복구가 가능하고 호출자가 그 처리를 해주길 바란다면 우선 옵셔널을 반환해도 될지 고민하자.

• 옵셔널만으로는 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.