ch10 예외 - LenKIM/everyone-is-effective-java-study GitHub Wiki

10장 예외

예외를 제대로 활용한다면 프로그램의 가독성, 신뢰성, 유지보수성이 높아지지만, 잘못 사용하면 반대의 효과가 나타난다.

그러므로, 우리는 예외를 효과적으로 활용하는 지침을 다뤄야 한다.

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

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

직관적이지 않다. 그러므로 위 코드처럼 작성하면 안된다. 왜? 이 코드는 배열의 원소를 순회하는데, 아주 끔찍한 방식으로 하고 있다. 무한루프를 돌다가 배열의 끝에 도달하면 예외 발생.

그러나 만약 이런 코드라면?

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

개발자는 곧바로 이해할 수 있다.

그럼에도 불구하고 예외를 써서 루프를 종료한 이유는 무엇일까? 잘못된 추론을 근거로 성능을 높여보려 한 것.
=> JVM은 배열에 접근할 때마다 경계를 넘지 않는지 검사하는데, 일반적인 반복문도 배열 경계에 도달하면 종료한다. 따라서 이 검사를 반복문에도 명시하면 같은 일이 중복되므로 하나를 생략한 것. 이는 세 가지 면에서 잘못한 것이다.

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

즉, 예외는 (그 이름이 말해주듯) 오직 예외 상황에서만 써야 한다. 절대로 일상적인 제어 흐름용으로 쓰여선 안 된다.

더 일반화해 이야기하면 표준적이고 쉽게 이해되는 관용구를 사용하고, 성능 개선을 목적으로 과하게 머리를 쓴 기법은 자제하라.

잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다.

= 특정 상태에서만 호출할 수 있는 '상태 의존적'메서드를 제공하는 클래스는 '상태 검사'메서드도 함께 제공해야 한다.

마치 next와 hasNext 처럼.

아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 세 가지를 제공하는데, 언제 무엇을 사용해야 하는지 헷갈려 한다.

호출하는 쪽에서 복구하리라 여겨지는 상황에서만 검사 예외를 사용하라.

이 말이 키포인트이다. 예외는 호출하는 쪽에서 복구하리라 여겨지는 상황에서만 검사 예외를 사용해야 한다.

이것이 검사와 비검사 예외를 구분하는 기본 규칙이다. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 띠리사 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출 했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것.

그럼 비검사 예외란 무엇인가?

바로 런타임 예외와 에러이다.

둘다 동작 측면에서는 다르지 않다.
프로그램에서 잡을 필요가 없거나 혹은 통상적으로는 잡지 말아야 한다. 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다. 이런 throwable을 잡지 않은 스레드는 적절한 오류 메세지를 내뱉으며 중단된다.

그러므로, 프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자. 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다. 전제조건 위배란 단순히 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 뜻이다. 다시 말해, 조건에 문제가 하나 있다면, 복구할 수 있는 상황인지 프로그래밍 오류인지가 항상 명확히 구분되지는 않는다는 사실이다.

예외는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다. 그러므로, Error 클래스를 상속해 하위 클래스를 만드는 일은 자제하자.

다시 말해 여러분이 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.(직접적이든 간접적이든). Error는 상속하지 말아야 할 뿐 아니라, throw 문으로 직접 던지는 일도 없어야 한다.

정리

복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자. 확실하지 않다면 비검사 예외를 던지자. 검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지도 말자.

검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자.

아이템 71. 필요 없는 검사 예외 사용은 피하라

검사 예외를 잘 활용하면, API와 프로그램의 질을 높일 수 있다. 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리, 검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높이게끔 해준다. 물론 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 된다.

API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자. 복구가 가능하고 호출자가 그 처리를 해주길 바란다면, 우선 옵셔널을 반환해도 될지 고민하자. 옵셔널만으로는 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.

아이템 72. 표준 예외를 사용하라

되도록 이면 표준 예외를 사용하자.

가장 많이 사용하는 예외로는 IllegalArgumentException이 있다. IlligalStateException 도 자주 재사용된다. 이 예외는 대상 객체의 상태가 호출된 메서드를 수행하기에 적합하지 않을 때 주로 던진다. 예컨데 제대로 초기화되지 않은 객체를 사용하려 할 때 던질 수 있다.

그 밖에

NullPointerException

IndexOutOfBoundsException

ConcurrentModificationException

UnsupportedOperationException

주의해야 될 점은, Exception RuntimeException, Throwable, Error 는 직접 재사용하지 말아야 한다. 이 클래스들은 추상 클래스라고 생각하자.

아이템 73. 추상화 수준에 맞는 예외를 던지라

추상화 수준에 맞는 예외란 무슨 말인가?

예시로 이런 말을 한다.

수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 것이다. 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 일어나는 일이다. 사실 이는 단순히 프로그래머를 당황시키는 데 그치지 않고, 내부 구현 방식을 드러내어 윗 레벨 API를 오염시킨다. 다음 릴리스에서 구현 방식을 바꾸면 다른 예외가 튀어나와 기존 클라이언트 프로그램을 깨지게 할 수도 있는 것.

그러므로, 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바뀌 던져야 한다. 이를 예외 번역(Exception translation)

try {
  ... // 저수준 추상화 이용
} catch (LowerLevelException e) {
  //추상화 수준에 맞게 번역한다.
  throw new HigerLevelException(...);
}

또 다른 예시로, AbstractSequentialList에서 수행하는 예외 번역을 보자.

AbstractSequentialList는 List 인터페이스의 골격 구현이다. 이 예에서 수행한 예외 번역은 List<E> 인터페이스의 get 메서드 명세에 명시된 필수 사항임을 기억해두자.

/**
* 이 리스트 안에 지정한 위치의 원소를 반환한다.
* @throws IndexOutOfBoundsException index가 범위 밖이라면,
*  즉 ({ @code index < 0 || index >= size()}) 이면 발생한다.
**/
public E get(int index) {
  ListIterator<E> i = listIterator(index);
  try {
    return i.next();
  } catch (NoSuchElementException e) {
    throw new IndexOutofBoundException("index: " + index);
  }
}

예외를 번역할 때, 저수준 예외가 디버깅에 도움이 된다면 예외 연쇄(exception chaining)를 사용하는게 좋다. 예외 연쇄란 문제의 근본 원인(cause) 인 저수준 예외를 고수준 예외에 실어 보내는 방식이다. 그러면 별도의 접근자 메서드(throwable의 getCause 메서드)를 통해 필요하면 언제든 저수준 예외를 꺼내볼 수 있다.

try {
  ... // 저수준 추상화 이용
} catch (LowerLevelException cause) {
  // 저수준 예외를 고수준 예외에 실어 보낸다.
  throw new HigerLevelException(cause);
}

무턱대고 예외를 전파하는 것보다야 예외 번역이 우수한 방법이지만, 그렇다고 남용해서는 곤란하다. 가능하다면 저수준 메소드가 반드시 성공하도록하여 아래 계층에서는 예외가 발생하지 않도록 하는 것이 최선이다. 때론 상위 계층 메서드의 매개변수 값을 아래 계층 메서드로 건네기 전에 미리 검사하는 방법으로도 사용될 수 있다.

또는 java.util.logging 같은 적절한 로깅 기능을 활용하여 기록해두면 좋다. 그렇게 해두면 클라이언트 코드와 사용자에게 문제를 전파하지 않으면서도 프로그래머가 로그를 분석해 추가 조치를 취할 수 있게 해준다.

아이템 74. 메서드가 던지는 모든 예외를 문서화하라

검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자.
메서드가 던질 수 있는 예외가 각각 @throws 태그로 문서화하되, 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자.
한 클래스에 정의된 많은 메서드가 같은 이유로 같은 예외를 던진다면 그 예외를 (각각의 메서드가 아닌)클래스 설명에 추가하는 방법도 있다.
=> NullPointerException 이 가장 흔한 사레다. 이럴 때는 클래스의 문서화 주석에 "이 클래스의 모든 메서드는 인수로 null이 넘어오면 NullpointerException을 던진다" 라고 적어도 좋다.

아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라

우리가 흔히 하는 예외를 할 때는 클래스 이름 뒤에 상세 메시지가 붙은 형태다.

사후 분석을 위해 실패 순간의 순황을 정확히 포착해 예외의 상세 메시지에 담아야 한다.

실패 순간을 포착하려면 발생한 예외의 관여된 모든 매개변수와 필드의 값을 실패 메시지를 담아야 한다. 예컨데 IndexOutOfBoundsExcpetion의 상세 메세지는 범위 최솟값과 최댓값, 그리고 그 범위를 벗어났다는 인덱스의 값을 담아야 한다.

관련 데이터를 모두 담아야 하지만 장황할 필요는 없다. 문제를 분석하는 사람은 스택 추적뿐 아니라 관련 문서와(필요하다면) 소스코드를 함께 살펴본다.

그러나, 예외의 상세 메시지와 최종 사용자에게 보여줄 오류 메시지를 혼동해서는 안 된다. 최종 사용자에게는 친절한 안내 메시지를 보여줘야 하는 반면, 예외 메시지는 가독성보다는 담긴 내용이 휠씬 중요하다.

또는 실패를 적절히 포착하려면 필요한 정보를 예외 생성자에서 모두 받아서 상세 메시지까지 미리 생성해놓는 방법도 괜찮다. 예를 들어 예외에 생성자로 String을 받지만, 아래와 같이 해도 된다.

// 실패 상황을 온전히 포착하도록 수정해본 IndexOutOfBoundsException (405쪽)
public class IndexOutOfBoundsException extends RuntimeException {
    private final int lowerBound;
    private final int upperBound;
    private final int index;

    /**
     * IndexOutOfBoundsException을 생성한다.
     *
     * @param lowerBound 인덱스의 최솟값
     * @param upperBound 인덱스의 최댓값 + 1
     * @param index      인덱스의 실젯값
     */
    public IndexOutOfBoundsException(int lowerBound, int upperBound,
                                     int index) {
        // 실패를 포착하는 상세 메시지를 생성한다.
        super(String.format(
                "최솟값: %d, 최댓값: %d, 인덱스: %d",
                lowerBound, upperBound, index));

        // 프로그램에서 이용할 수 있도록 실패 정보를 저장해둔다.
        this.lowerBound = lowerBound;
        this.upperBound = upperBound;
        this.index = index;
    }
}

아이템 76. 가능한 한 실패 원자적으로 만들라

작업 도중 예외가 발생해도 그 객체는 여전히 정상적으로 사용할 수 있는 상태라면 멋지지 않는가? 검사 예외를 던진 경우라면 호출자가 오류 상태를 복구할 수있을 테니 더욱 유용할 것.

일반화해 이야기하면, 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 이러한 특성을 실패 원자적(failure-atomic)

그럼 어떻게 실패 원자적으로 만들 수 있을까?

가장 간단한 방법은 불편 객체로 설계하는 것.
그렇다면 가변 객체의 메서드를 실패 원자적으로 만드는 가장 흔한 방법은 작업 수행에 앞서 매개변수의 유효성을 검사하는 것이다. 객체의 내부 상태를 변경하기 전에 잠재적 예외의 가능성 대부분을 걸러낼 수 있는 방법이다.
객체의 임시 복사본에서 작업을 수행한 다음, 작업이 성공적으로 완료되면 원래 객체와 교체하는 것이다. 데이터를 임시 자료구조에 저장해 작업하는 게 더 빠를 때 적용하는 방법.
작업 도중 발생하는 실패를 가로채는 복구 코드를 작성하여 작업 전 상태로 되돌리는 방법. 주로 디스크 기반의 내구성을 보장해야 하는 자료구조에 쓰이는데, 자주 쓰이는 방법은 아니다.

그러나, 아예 만들 수 없는 실패 원자적도 있다. 바로 멀티 스레드에서는 만들 수 없다.

여기서 중요한 것은 메서드 명세에 기술한 예외라면 설혹 예외가 발생하더라도 객체의 상태는 메서드 호출 전과 똑같이 유지돼야 한다는 것이 기본 규칙이다. 이 규칙을 지키지 못한다면 실패 시의 객체 상태를 API 설명에 명시해야 한다.

아이템 77. 예외를 무시하지 말라

왜 우리는 예외를 명시하는 이유가 무엇인가?

API 설계자에게 메서드 선언에 예외를 명시하는 이유는 그 메서드를 사용할 때 적절한 조치를 취해달라고 말하는 것이다. 그러므로 우리는 예외를 무시하면 안된다.

// catch 블록을 비워두면 예외가 무시된다. 아주 의심스러운 코드다.
try {
  ...
} catch (SomeException e){
}

예외는 문제 상황에 잘 대처하기 위해 존재하는데 catch 블록을 비워두면 예외가 존재할 이유가 없어진다.

당연히 무시해야 할 때도 있다. FileInputStream 을 닫을 때, 파일의 상태를 변경하지 않았으니 복구할 것이 없으며, 필요한 정보는 이미 다 읽었다는 뜻이니 남은 작업을 중단할 이유가 없다. 그러므로, 예외를 무시하기로 했다면 catch 블록 안에 그렇게 결정한 이유를 주석으로 남기고 예외 변수의 이름도 ignored로 바꿔놓도록 하자.

try{
  ...
} catch (TimeoutException | ExecutionException ignored){
  // 기본값을 사용한다(색상 수를 최소화하면 좋지만, 필수는 아니다.)
}

이 내용은 검사와 비검사 예외 모두에 똑같이 적용된다. 예측할 수 있는 예외 상황이든 프로그래밍 오류든, 빈 catch 블록으로 못 본 척 지나치면 그 프로그램은 오류를 내재한 채 동작하게 된다.

그런 작은 코드들이 쌓이다보면, 아무 상관없는 코드 때문에 죽을 수도 있다.

예외를 적절히 처리하면 오류를 완전히 피할 수도 있다. 무시하지 않고 바깥으로 전파되게만 놔둬도 최소한 디버깅 정보를 남긴 채 프로그램이 신속히 중된되게는 할 수 있다.