[이펙티브자바] 아이템69-예외는 진짜 예외 상황에만 사용하라 신중히 하라

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

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

위 코드는 직관적인 않을 뿐만 아니라, 배열의 원소를 아주 끔찍하게 순회하고 있다.
무한 루프를 돌다가 배열의 끝에 도달해 예외(ArrayIndexOutOfBoundsException)가 발생하면 끝을 내는 코드이다.
이렇게 예외로 루프를 종료한 이유는 잘못된 추론을 근거로 성능을 높여보려 한 것이다.
- JVM은 배열에 접근할 때마다 경계를 넘지 않는지, 검사하는데, 일반적인 반복문도 배열 경계에 도달하면 종료한다.
- 따라서 이 검사를 반복문에도 명시하면 같은 일이 중복되므로 하나를 생략한 것이다.
- 하지만 세 가지면에서 잘못된 추론이다.

1) 예외는 예외 상황에 쓸 용도로 설계되었으므로 JVM 구현자 입장에서는 명확한 검사만큼 빠르게 만들어야 할 동기가 약하다.(최적화에 신경쓰지 않았을 가능성이 크다.)

2) 코드를 try-catch 블록 안에 넣으면 JVM이 적용할 수 있는 최적화가 제한된다.

3) 배열을 순회하는 표준 관용구는 앞서 걱정한 중복 검사를 수행하지 않는다. JVM이 알아서 최적화해서 없애준다.

실상은 예외를 사용한 쪽이 표준 관용구보다 훨씬 느리다. 필자의 컴퓨터에선 원소100개짜리 배열로 테스트해보니 2배 정도 느리다고 한다.

반복문의 몸체에서 호출한 메서드가 내부에서 관련 없는 배열을 사용하다 ArrayIndexOutOfBoundsException을 일으켰다고 해보자.
표준 관용구였다면 이 버그는 예외를 잡지 않고(스택 트레이스를 남기고) 해당 스레드를 즉각 종료시킬 것이다.
반면 예외를 사용한 반복문은 버그 때무에 발생한 엉뚱한 예외를 정상적인 반복문 종료 상황으로 오해하고 넘어갈 것이다.

특정 상태에서만 호출할 수 있는 상태 의존적 메서드를 제공하는 클래스는 상태 검사 메서드도 함께 제공해야 한다.
Iterator 인터페이스의 next와 hasNext 가 각각 상태 의존적 메서드와 상태 검사 메서드에 해당된다. 이러한 메서드 덕분에 for 관용구를 사용할 수 있다.
- for-each도 내부적으로 hasNext를 사용한다.

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

Iterator가 hasNext()를 제공하지 않았다면 그 일을 클라이언트가 대신해야만 했다.

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

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