[아이템 71] 필요 없는 검사 예외 사용은 피하라

아이템 70에서 Checked Exception과 Unchecked Exception에 대해 다루었습니다.

Checked Exception은 try-catch 블록으로 감싸거나 예외를 던지는 행위를 강제하기 때문에 싫어하는 자바 개발자가 많지만 제대로 활용할 경우 API와 프로그램의 질을 높일 수 있습니다.

Checked Exception은 다음과 같은 상황에서 적절하며, 이에 해당하지 않는 경우에는 Unchecked Exception을 사용하는 것이 적절합니다.

• API를 제대로 사용해도 발생할 수 있는 예외
• 프로그래머가 의미 있는 조치를 취할 수 있는 경우

 

요약하면, Checked Exception은 특정한 상황에서만 사용하는 것이 좋으며, 일반적으로는 Unchecked Exception을 선호합니다.

보통 필요 없는 Checked Exception 사용은 단 하나의 Checked Exception을 사용할 때 발생하며 대처법은 다음과 같습니다.

• 적절한 결과 타입을 담은 Optional을 반환하자
• 메서드를 쪼개자

 

1. 적절한 결과 타입을 담은 Optional을 반환하자

 

해당 방법은 Checked Exception을 던지는 대신 단순히 빈 Optional을 반환하는 것이지만 예외가 발생하는 이유를 알려주는 부가 정보를 담을 수 없다는 단점이 존재합니다.

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

 

1.1 빈 Optional을 반환하는 경우

 

1.2 Checked Exception을 반환하는 경우

예제 자체는 Unchecked Exception을 예로 들었지만 Checked Exception도 동일한 맥락을 따릅니다.

 

 

2. 메서드를 쪼개자

 

해당 방법은 Checked Exception을 던지는 메서드를 두 개로 분리하고, 그 대신 Unchecked Exception을 던지도록 변경하는 방법입니다.

문제가 발생하는 지점을 상태 검사 메서드로 체크 후 통과하는 케이스에만 로직을 실행하는 방식입니다.

 

단 이 방식의 문제점은 아이템 69에서 언급했듯이 멀티 쓰레드 환경에서 동기화 없이 위와 같이 리팩토링 진행 시, 메서드 검사 시점과 메서드 호출 시점 사이에 상태가 변경될 수 있고, 중복 수행이 발생할 수 있다는 단점이 존재합니다.

 

정리

• Checked Exception은 프로그램의 안전성을 높여주지만 남용하면 예외 처리를 모든 layer에서 처리해야 하므로 반드시 필요한 곳에만 Checked Exception을 사용하자
• API 호출자가 예외 상황에서 복구할 방법이 없을 경우 비검사 예외를 던지자
  • 복구가 가능하고 호출자가 복구 로직을 수행하길 원한다면 우선 Optional을 반환해도 될지 고민하자
  • Optional만으로는 충분한 정보를 제공하지 못한다면 Checked Exception을 던지자

 

참고

이펙티브 자바