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

// 예외를 사용해 복잡하게 만든 코드
try{
	int i = 0;
	while(true)
		range[i++].climb();
	} catch (ArrayIndexOutOfBoundsException e) {
			//
	}

// 표준적인 관용구대로 작성한 코드 
for (Mountain m : range)
	m.climb();

예외를 발생시켜 아주 끔찍한 방법으로 반복을 종료한 코드가 예로 나와있다. 왜 알기쉽고 보기쉬운 표준적인 관용구 for를 사용하지 않고 예외를 사용했을까?

• 잘못된 추론을 근거로 성능을 높여보려고 한 것이다.
• JVM은 배열에 접근할 때마다 경계를 넘지 않는지 검사하는데, 일반적인 반복문도 배열 경계에 도달하면 종료한다. → 이 검사를 반복문에도 명시하면 일이 중복된다 → 중복되니까 하나를 생략하자! 대신 예외를 넣자. → 그러나 잘못된 추론이다.
  1. 예외는 예외의 상황에 쓸 용도로 설계되었으므로 JVM 구현자 입장에서는 명확한 검사만큼(일반적으로 사용되는 기능)만큼 빠르게 만들어야 할 필요를 못 느낀다. 최적화에 별로 신경을 쓰지 않았다는 뜻이다.
  2. 배열을 순회하는 표준 관용구는 앞서 언급한 중복 검사를 수행하지 않는다. JVM이 알아서 최적화를 하기 때문이다.
  3. try-catch 블록 안쪽에 있는 코드는 JVM이 적용할 수 있는 최적화가 제한된다.

실상은 에외를 사용한 쪽이 표준 관용구보다 훨씬 느리다. 예외를 사용한 반복문의 해악은 코드를 헷갈리게 하고 성능을 떨어뜨리는데서 끝나지 않는다. 심지어 제대로 동작하지 않을 수도 있다. 반복문 안에 버그가 숨어있다면 흐름 제어에 쓰인 예외가 이 버그를 숨겨 디버깅을 훨씬 어렵게 할 것이다.

→ 반복문의 몸체에서 호출한 메서드가 내부에서 관련 없는 배열을 사용하다가 ArrayIndexOutOfBoundsException을 일으켰다면 표준 관용어구에서는 해당 스레드를 즉각 종료할 것이다. 그러나 예외를 사용했다면 반목문은 버그 때문에 값이 잘못되었는데도 정상적 작동이라 생각하여 상황을 오해하고 넘어간다.

표준적이고 쉽게 이해되는 관용구를 사용하고, 성능 개선을 목적으로 과하게 머리를 쓴 기법은 자제하자. 실제로 성능이 좋아지더라도 자바 플랫폼이 꾸준히 개선되고 있으니 최적화로 얻은 상대적인 성능 우위가 오래가지 않을 수 있다. 반면 과하게 영리한 기법에 숨겨진 미묘한 버그의 페해와 어려워진 유지보수 문제는 계속 이어질 것이다.

특정 상태에서만 호출할 수 있는 '상태 의존적' 메서드를 제공하는 클래스는 '상태 검사' 메서드고 함께 제공해야 한다. (ex: Iterator 인터페이스의 next와 hasNext

// 상태 검사 메서드 사용!
for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) {
		Foo foo = i.next();
		....
}

// 상태 검사 메서드가 없다면 클라이언트가 하게 될 일
// 절대 이런 예외를 발생시키는 방식으로 컬렉션 순회하지 말 것

try {
	Iterator<Foo> i = collection.iterator();
	while(true) {
		Foo foo = i.next();
		...
		}
	} catch (NoSuchElementException e) {
	}

상태 검사 메서드가 없었다면 우리는 반복문에 에외를 사용해서 장황하고 헷갈리고, 속도도 느리고 엉뚱한 곳에서 발생한 버그를 숨기는 코드를 작성하게 된다. 그런데 상태 검사 메서드 대신 사용할 수 있는 선택지도 있다. 옵셔널 혹은 null과 같은 특수한 값을 반환하는 것이다!

1. 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인으로 상태가 변할 수 있다면 옵셔널이나 특정 값을 사용한다. 상태 검사 메서드와 상태 의존메서드 호출 사이에 객체의 상태가 변할 수 있기 때문이다.
2. 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 중복 수행한다면 옵셔널을 반환하자.
3. 이외에 모든 경우엔 상태 검사 메서드 방식이 조금 더 낫다. 가독성이 살짝 더 좋고, 잘못 사용했을 때 발견도 쉽다. 또한 상태 검사 메서드 호출을 깜빡했다면 상태 의존 메서드가 예외를 확실하게 던져서 버그를 잘 보여줄 것이다.

예외는 예외 상황에서 쓸 의도로 설계되었다. 정상적인 제어 흐름에서 사용해서는 안되며, 이를 프로그래머에게 강요하는 API를 만들어서도 안된ㄷ