아이템 69 : 예외는 진짜 예외 상황에만 사용하라

예외 잘못 사용한 예

try {
		int i = 0;
		while(true) 
				range[i++].climb();
} catch (ArrayIndexOutOfBoundsException e) {
}

for (Mountain m : range) 
	m.climb();

• 위의 사례는 잘못된 추론을 근거로 성능을 높여보려 한 것임. JVM은 배열에 접근할 때마다 경계를 넘지 않는지 검사하는데, 일반적인 반복문도 배열 경계에 도달하면 종료함. 따라서 이 검사를 반복문에도 명시하면 같은 일이 중복되므로 하나를 생략한 것임

• 가독성도 떨어지고, 실제로 예외 상황이 발생했을 때에는 아래 반복문에서는 stack trace를 남기는 반면 위에서는 그냥 먹어버림. 아주 위험하다

API 설계 에서의 예시

• 특정 상태에서만 호출할 수 있는 ‘상태 의존적’인 메서드를 제공하는 클래스는 ‘상태 검사’ 메서드도 함께 제공해야 한다 (Iterator 인터페이스의 next와 hasNext 가 각각 상태 의존적 메서드와 상태 검사 메서드에 해당함)

for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) {
	Foo foo = i.next();
	...
}

상태 검사 메서드 대신 사용할 수 있는 선택지

• 올바르지 않은 상태일 때 빈 옵셔널 or null 같은 특수한 값 반환

• 상태 검사 메서드, 옵셔널, 특정 값 중 하나를 선택하는 지침
1. 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인으로 상태가 변할 수 있다면 옵셔널이나 특정값을 사용함. 상태 검사 메서드와 상태 의존적 메서드 호출 사이에 객체의 상태가 변할 수 있기 때문
2. 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 중복 수행한다면 옵셔널이나 특정 값을 선택
3. 다른 모든 경우엔 상태 검사 메서드 방식이 조금 더 나음. 가독성이 살짝 더 좋고, 잘못 사용했을 때 발견하기 쉬움. 상태 검사 메서드 호출을 깜빡 잊었다면 상태 의존적 메서드가 예외를 던져 버그를 확실히 드러냄. 반면 특정 값은 검사하지 않고 지나쳐도 발견하기 어려움(옵셔널에는 해당하지 않는 문제)