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

EFFECTIVE JAVA(이펙티브 자바)

 

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다.

---

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

 

검사 예외

• 검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높일 수 있게 해준다.
• 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 될 수 있다.
• 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리학나 더 바깥으로 던져 문제를 전파해야만 한다.
• 어느 쪽이든 API사용자에게 부담을 준다.
• API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미있는 조치를 취할 수 있는 경우라면 이러한 단점을 감수하고도 사용하는 것이 좋고, 둘 중 어디에도 속하지 않는다면 비검사 예외를 사용하는 게 좋다.
• 검사 예외를 단 하나만 사용한다면, 검사 예외를 안던지는 방향도 고려해보자. (검사 예외를 하나라도 넣으면, API 사용자는 try블록을 추가해야하기 때문)

 

 

검사 예외를 회피하는 방법

• 가장 쉬운 방법은 적절한 결과 타입을 담은 옵셔널을 반환하는 것이다.
  • 검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환하는 것.
  • 단점 : 예외가 발생한 이유를 알려주는 부가 정보를 담을 수 없음
• 검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 바꾸는 것.

 

 

ex 1) 검사 예외를 던지는 메서드 (리펙터링 전)

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

 

ex 2) 상태 검사 메서드와 비검사 예외를 던지는 메서드 (리펙터링 후)

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

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

 

정리

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