이펙티브 자바, 쉽게 정리하기 - item 69. 예외는 진짜 예외 상황에만 사용하라

이펙티브 자바, 쉽게 정리하기 - item 69. 예외는 진짜 예외 상황에만 사용하라

예외가 아닌 상황에 예외를 사용했을 때

try {
  int i = 0;

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

}

• 위 코드의 의도는 일반적인 반복문에서 반복문도 매 반복마다 배열의 경계를 넘는지 검사하고, JVM도 배열에 접근할 때마다 경계를 넘는지 검사하는데, 그 중복을 없애서 성능 최적화를 하려던 의도이다.
  • 결과적으로는 잘못된 추론을 근거로 성능을 높여보려 한 것이 된다.

위 추론이 잘못된 이유

• JVM 구현자 입장에서는 위 같은 코드가 빠르게 돌아갈지에 대해서는 전혀 고려하지 않을 것이다.
  • 예외는 예외를 처리하는데 쓰라는 구현자의 의도와 다르게 코드를 작성했기 때문이다.
  • 예외를 로직에 이용하면 안된다.
• 코드를 try-catch 블록 안에 넣으면, JVM 이 적용할 수 있는 최적화가 제한된다.
• 배열을 순회하는 표준 관용구는 앞서 걱정한 중복 검사를 수행하지 않는다.
  • JVM 은 똑똑하기 때문에 이미 이러한 최적화가 되어 있다.

예제 코드변화: 모범적인 코드

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

• 의미도 알기 쉽고, 헷갈릴 일이 없다.

성능 테스트

그렇다면 성능은 정말로 빨라졌을까?

@Test
public void exceptionTest() {
    int i = 0;
    int[] arr = new int[100_000_000];

    try {
        while (true) {
            arr[i] = i++;
        }
    } catch(ArrayIndexOutOfBoundsException e) {
        e.printStackTrace();
    }
}

@Test
public void loopTest() {
    int size = 100_000_000;
    int[] arr = new int[size];

    for (int i = 0; i < size; i++) {
        arr[i] = i;
    }
}

• exceptionTest 와 loopTest 의 성능차이는 매우 미미하긴 한데, loopTest가 더 빠르다.
  • 편법으로 최적화를 해봤자 코드만 복잡해지고, 실제 JVM 이 최적화 해준 기본형에 속도가 밀린다는 것이다.

기타 상태 검사 메서드의 경우

• 상태 검사 메서드란, Iterator.hasNext() 와 같이 객체의 상태를 검사하는 메서드를 말한다.
  • Iterator.next() 와 같이 상태 의존적인 메서드를 사용할 때 필수적으로 상태를 검사해야 한다.

직접 상태검사 메서드를 이용하는 for 문

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

• hasNext() 를 이용하여 올바르게 순회하고 있다.
• for-each 를 사용해도 내부적으로 hasNext() 를 사용하기 때문에 사실 for-each 를 사용하는 것이 더 깔끔하다.

상태검사 메서드를 이용하지 않고 예외처리 하는 for 문

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

• 반복문 로직 탈출을 예외로 하고 있다. 바람직하지 않다.

교훈

• 예외는 정말로 예외 상황에서만 쓰자.
  • 일상적인 제어 흐름으로 쓰지 말자.
  • 실제로 성능이 상승하더라도 매우 미약한 수준이며, 언제든 JVM의 발전에 의해 따라잡힐 수 있다.
  • 어려운 유지보수 문제는 덤이다.
• 잘 설계된 API는 클라이언트가 정상적 흐름에서 예외를 사용할 일은 없다.
  • 특정 상태에서만 호출 가능한 '상태 의존적' 메서드를 제공하는 클래스는 '상태 검사' 메서드도 함께 제공해야 한다.
    • Iterator 인터페이스의 next 와 hasNext 가 각각 상태 의존적 메서드와 상태 검사 메서드에 해당한다.
    • 위와 같은 별도의 상태 검사 메서드 덕에 for-each 를 사용할 수 있다. (내부적으로 hasNext 를 사용)
  • '상태 검사' 메서드 외에 빈 Optional 혹은 null 과 같은 특수 값을 반환하는 방법도 있다.
• 상태 의존적 메서드에서 상태 검사 메서드, Optional, 특정 값 반환 중 선택 방법
  • 외부 요인으로 상태가 변할 수 있다면, Optional 혹은 특정 값
  • 성능이 중요한데 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 수행한다면, Optional 혹은 특정 값
  • 다른 모든 경우엔 상태 검사 메서드가 낫다.
    • 가독성이 좋고 잘못 사용했을 때 발견하기 쉽다.
    • 호출을 깜빡했을 때 예외를 던져 버그를 확실히 드러낼 것이다.
    • 특정 값은 검사하지 않고 지나쳐도 발견하기 어렵다.

핵심 정리

• 정상적인 제어 흐름에서 예외를 사용하지 말자.
  • 이를 프로그래머에게 강요하는 API도 만들지 말자.