[Effective Java] 69.예외는 진짜 예외 상황에서만 사용하라

// 예외를 완전 잘못 사용한 예
try {
    int i = 0;
    while (true) {
        range[i++].climb();
    }
} catch (ArrayIndexOutOfBoundsException e) {
}

위 코드는 직관적이지 않게 예외를 작성하였다.

무한루프를 돌다가 배열의 끝에 도달해 예외가 발생하면 끝을 내는 것이다.

이 코드를 아래와 같이 작성 했다면 모든 프로그래머가 이해할 수 있을 것이다.

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

그런데 예외를 쓴 이유가 무엇일까?

3가지 면에서 잘못된 추론을 해서 예외를 사용한게 더 성능이 좋을 것이라고 생각했을 가능성이 있다.

이를 바로잡고자 한다.

 

1) 예외는 예외상황에 쓸 용도로 설계되어서 JVM 구현자 입장에서는 명확한 검사만큼 빨라야 할 동기가 약해 최적화에 별로 신경을 안 썼을 것이다.

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

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

 

예외는 제대로 동작하지 않을 수도 있다.

반복문 안에 버그가 숨어 있다면 예외가 이 버그를 숨겨 디버깅을 훨씬 어렵게 할 것이다.

→ 예외는 오직 예외 상황에서만 써야 한다. 일상적인 제어 흐름용 x (API 설계에서도 적용)

 

 

상태 검사 메서드 제공하기

• 특정 상태에서만 호출할 수 있는 상태의존적 메서드를 제공하는 클래스는 상태 검사 메서드도 함께 제공해야함 ex) Iterator 인터페이스의 next(상태의존적 메서드)와 hasNext(상태 검사 메서드)
• 제공 안하면 클라이언트에서 그 일을 강제해야 하는 문제.
• 올바르지 않은 상태일 때 빈 옵셔널[아이템 55]이나 null 같은 특수한 값 반환하는 방법도 있음
• 상태 검사 메서드, 옵셔널, 특정 값 중 하나를 선택하는 지침
  • 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인으로 상태가 변할 수 있다면 옵셔널이나 특정 값 사용 (상태 의존적 메서드와 상태 검사 메서드 호출 사이에 객체 상태가 변할 수 있어서)
  • 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 중복 수행한다면 옵셔널이나 특정 값 선택
  • 다른 모든 경우엔 상태 검사 메서드가 더 나음 (가독성이 조금 더 좋고 오류를 발견하기 쉬움). 상태 검사 메서드 호출을 까먹었다면 상태 의존적 메서드가 버그를 던져 확실히 알 수 있음 → 특정 값을 사용했다면 검사하지 않고 지나쳐도 발견하기 어려움(옵셔널은 해당하지 않음)

 

 

결론

예외는 예외상황에서만 쓰도록 하라.

정상적인 제어 흐름에서 사용하지 말고 프로그래머에게 강요하는 API를 만들어서도 안됨