69. 예외는 진짜 예외 상황에만 사용하라

예외 상황

예외를 완전히 잘못 사용한 예

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

위 코드는 잘못된 추론을 근거로 성능을 높이려고 하고 있다.JVM은 배열의 원소에 접근할 때마다 경계를 넘지 않는지 검사한다. 따라서 이 검사를 반복문에도 적용할 경우 같은 일이 중복되므로 하나를 생략한 것이다. 하지만 이 추론은 세 가지 근거에서 잘못됐다.

• 예외는 예외 상황에 쓸 용도로 설계되었기 때문에 JVM 구현자 입장에서는 명확한 검사만큼 빠르게 만들어야 할 동기가 약하다.
• 코드를 try-catch 블록 안에 넣으면 JVM이 적용할 수 있는 최적화가 제한된다.
• 배열을 순회하는 표준 관용구는 앞서 걱정한 중복 검사를 수행하지 않는다. JVM이 알아서 최적화해 없애준다.

예외는 예외적인 상황에만 써야한다. 절대로 일상적인 제어 흐름용으로 쓰여선 안된다. 이 원칙은 API 설계에도 적용된다. 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다. 특정 상태에서만 호출할 수 있는 상태 의존적 메서드를 제공하는 클래스는 상태 검사 메서드를 함께 제공해야 한다. iterator의 next와 hasNext가 그 예이다.

상태검사 메서드 대신 선택할 수 있는 방안도 몇개 있다. 올바르지 않은 상태일 때 빈빈 Optional 메서드나 return null 이 그 예이다. 이를 선택하는 다음 지침을 보자.

• 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인으로 상태가 변할 수 있다면 Optional이나 특정 값을 사용한다. 상태 검사 메서드와 상태 의존적 메서드 호출 사이에 객체의 상태가 변할 수 있기 때문이다.
• 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 중복 수행한다면 옵셔널이나 특정 값을 선택한다.
• 다른 모든 경우에는 상태 검사 메서드 방식이 조금 더 낫다고 할 수 있다. 가독성이 살짝 더 좋고, 잘못 사용했을 때 발견하기 쉽다. 상태 검사 메서드 호출을 잊었다면, 상태 의존적 메서드가 예외를 던져 버그를 확실히 드러낸다.