이펙티브 자바 - 10장 : 예외

예외

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

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

try {
    int i = 0;
    while(true) { // 절대 좋지 않은 코드
        range[i++].climb();

    }
} catch (ArrayIndexOutOfBoundsException e){

}
for (Mountain m : range) { // 표준적인 관용구로 하면 이해하기 쉽고 try는 필요하지 않다,
    m.climb();
}

• 예외를 완전히 잘못 사용한 예시이다.
• 무슨 일을 하는 코드인지 알 수 없고 직관적이지 않다.

예외를 이용해 성능을 높이려는 잘못 된 추론

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

잘못된 예외의 안 좋은 점

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

• 예외는 (그 이름이 말해주듯) 오직 예외 상황에서만 써야 한다. 절대로 일상적인 제어 흐름용으로 쓰여선 안 된다.
• 표준적이고 쉽게 이해되는 관용구를 사용하고, 성능 개선을 목적으로 과하게 머리를 쓴 기법은 자제하라.
• 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다.
  • 특정 상태에서만 호출할 수 있는 '상태 의존적' 메서드를 제공하는 클래스는 '상태 검사' 메서드도 함께 제공해야 한다.
  • Iterator 인터페이스의 next와 haNext가 각각 상태 의존적 메서드와 상태 검사 메서드에 해당한다.
  • for-each 내부적으로 hasNext를 사용하여 아래와 같이 사용할 수 있다.

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

• 상태 검사 메서드 대신 사용할 수 있는 선택지로 올바르지 않은 상태일 때 옵셔널 혹은 null 같은 특수한 값을 반환하는 방법이다.

상태 검사 메서드, 옵셔널, 특정 값 중 하나를 선택하는 지침

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

⇒ 직관적이지 않다는 사실(아이템67), 옵셔널(아이템55)

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

---

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

자바는 문제 상황을 알리는 타입으로 검사 예외, 런타임 예외, 에러 세 가지를 제공하는데 언제 무엇을 사용해야 하는지 헷갈려 하는 프로그래머들이 종종 있다. 100% 명확한건 아니지만 참고할 만한 지침을 제공한다.

예외를 사용해야 하는 상황

1. 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.
   • 검사와 비검사 예외를 구분하는 기본 규칙으로 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.
   • API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구하고 사용자는 예외를 잡기만 하고 별다른 조치를 취하지 않을 수도 있지만 이는 좋지 않는 생각이다.
   • 비검사 throwable은 두 가지로 런타임 예외와 에러이다.
     1. 동작 측면에서는 다르지 않고 프로그램에서 잡을 필요가 없거나 혹은 통상적으로는 잡지 말아야 한다.
     2. 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다 실이 많다는 의미로 throwable을 잡지 않은 스레드는 적절한 오류 메시지를 내뱉으며 중단된다.
2. 프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자.
   • 전제조건을 만족하지 못했을 때 발생하는 오류로 단순히 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 의미이다.
   • 복구할 수 있는 상황인지 프로그래밍 오류인지 명확히 구분되지는 않는 점이 있다.
     • 예를 들어 자원 고갈은 프로그래밍 오류일 수도 있고 진짜 자원이 부족해서 발생한 문제일 수 있다. 자원이 일시적으로만 부족하거나 수요가 순간적으로만 몰린 것이라면 충분히 복구할 수 있는 상황이다.
   • 복구 가능하다고 믿는다면 검사 예외를 그렇지 않다면 런타임 예외를 사용하자.
   • 확신하기 어렵다면 아마도 비검사 예외를 선택하는 편이 나을 것이다.
3. 여러분이 직간접적으로구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.
   • 에러는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용하고 자바 언어 명세가 요구하는 것은 아니지만 널리 퍼진 규약이니, Error 클래스를 상속해 하위 클래스를 만드는 일은 자제해야 한다.
   • Error는 상속하지 말아야 할 뿐 아니라, throw문으로 직접 던지는 일도 없어야 한다.(AssertionError는 예외다.)
   • Exception, RuntimeException, Error를 상속하지 않는 throwable을 만들 수도 있고 자바 명세에서 직접 다루지 않지만 암묵적으로 일반적인 검사 예외(Exception의 하위 클래스 중 RuntimeException을 상속하지 않은)처럼 다룬다.
   • throwable은 이로울게 없으니 절대 사용하지 말자! throwable은 정상적인 검사 예외보다 나을게 하나도 없으면서 API 사용자를 헷갈리게 할 뿐이다.
4. API 설계자들도 예외 역시 어떤 메서드라도 정의할 수 있는 완벽한 객체라는 사실을 잊곤한다.
   1. 예외의 메서드는 주로 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는데 쓰이며 이런 메서드가 없다면 프로그래머들은 오류 메시지를 파싱해 정보를 빼내야 하는데, 대단히 나쁜 습관이다.
   2. throwable 클래스들은 대부분 오류 메시지 포맷을 상세히 기술하지 않는데, JVM이나 릴리스에 따라 포맷이 달라질 수 있다는 의미로 메시지 문자열을 파싱해 얻은 코드는 깨지기 쉽고 다른 환경에서 동작하지 않을 수 있다.
5. 검사 예외는 일반적으로 복구할 수 있는 조건일 때 발생한다.
   1. 호출자가 예외 상황에서 벗어나는데 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다.
   2. 예를 들어 물건을 구입하려는데 잔고가 부족하여 검사 예외를 발생했다고 했을 경우에 예외는 잔고가 얼마나 부족한지를 알려주는 접근자 메서드를 제공해야 한다.

⇒ 예외를 잡기만 하고 별다른 조치를 하지 않을 수 있지만(아이템77), 비검사 예외(아이템71), 파싱해 정보를 빼내야 하는 나쁜 습관이다(아이템12)

복구할 수 있는 상황이면 검사 예외를,
프로그래밍 오류라면 비검사 예외를 던지자.
확실하지 않다면 비검사 예외를 던지자.
검사 예외도 런터임 예외도 아닌 throwable은 정의하지도 말자. 검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자.

---

아이템 71 : 필요 없는 검사 예외는 사용을 피해라

• 검사 예외를 싫어하는 자바 프로그래머가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다.
• 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리, 검사 예외는 발생한 문제를 프로그래머가 처리하여 안전성을 높이게끔 해준다.

검사 예외는 남용되어서는 안된다.

• 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 되므로 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야 한다.
• 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바 8부터는 부담이 더욱 커졌다.
• API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우라면 이정도 부담을 받아들일 수 있지만 두 가지에 해댕하지 않는다면 비검사 예외를 사용하는게 좋다.

// 검사 예외와 비검사 예외 중 어느 것을 선택해야 할지는 프로그래머가 그 예외를 어떻게 다룰지 생각해보면 알 수 있다.
} catch (TheCheckedException e) {
    throw new AssertionError(); // 일어날 수 없다!
}

} catch (TheCheckedException e) {
    e.printStackTrace(); // 안되겠다 에러를 보자!
    System.exit(1);
}

• 더 나은 방법이 없다면 비검사 예외를 선택해야 한다.

검사 예외를 안 던지는 방법을 고민해야 하는 경우

• 검사 예외가 프로그래머에게 지우는 부담은 메서드가 단 하나의 검사 예외만 던질 때가 특히 크고 이미 다른 검사 예외도 던지는 상황에서 또 다른 검사 예외를 추가하는 경우라면 기껏해야 catch문 하나 추가하는 선에서 끝이다.
• 검사 예외가 단 하나뿐이라면 오직 그 예외 때문에 API 사용자는 try블록을 추가해야 하고 스트림에서 직접 사용하지 못하게 되니 이런 상황이라면 검사 예외를 안 던지는 방법이 없는지 고민해볼 가치가 있다.

검사 예외를 회피하는 가장 쉬운 방법

• 적절한 결과 타입을 담은 옵셔널을 반환하거나 검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환하면 되고
• 옵셔널을 던졌을 경우 단점은 예외가 발생한 이유를 알려주는 부가 정보를 담을 수 없고 예외를 사용하면 구체적인 예외 타입과 타입이 제공하는 메서드들을 활용해 부가 정보를 제공할 수 있다.
• 검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 바꿀 수 있다.

    // 검사 예외를 던지는 메서드 - 리팩토링 전
    try {
        obj.action(args);
    } catch (TheCheckedException e) {
    }
  
    // 상태 검사 메서드와 비검사 예외를 던지는 메서드 - 리팩토링 후
    if (obj.actionPermitted(args) {
        obj.action(args);
    } else {
  
    }

  • 위 리팩토링은 모든 상황에서 적용할 수는 없지만 적용할 수 있다면 더 쓰기 편한 API를 제공한다.
  • 코드가 깔끔하지 않지만 유연한 것은 확실하고 프로그래머는 메서드가 성공하리라는 걸 안다거나 실패 시 스레드를 중단하길 원한다면 다음처럼 한 줄로 작성할 수도 있다.

    obj.action(args);

  • 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인에 의해 상태가 변할 수 있다면 리팩터링은 적절하지 않다.
  • actionPermitted와 actionn 호출 사이에 객체의 상태가 변할 수 있기 때문이다.

⇒ 스트림(아이템45~48), 옵셔널(아이템55), 예외(아이템70)

꼭 필요한 곳에만 사용한다면 검사 예외는 프로그램의 안전성을 높여주지만, 남용하면 쓰기 고통스러운 API를 낳는다. API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자. 복구가 가능하고 호출자가 그 처리를 해주길 바란다면, 우선 옵셔널을 반환해도 될지 고민하자. 옵셔널만으로는 상황을 처리하기에는 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.

---

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

숙련된 프로그래머는 그렇지 못한 프로그래머보다 더 많은 코드를 재사용한다.

에외도 마찬가지로 재사용하는 것이 좋으며, 자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공한다.

표준 예외를 사용하면 좋은 점

1. 다른 사람이 익히고 사용하기 쉬워진다.
2. 많은 프로그래머에게 이미 익숙해진 규약을 그대로 따르기만 하면 된다.
3. API를 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다는 장점도 크다.
4. 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다.

특정한 상황에는 재사용보다 알맞는 예외를 던지자.

가장 많이 재사용되는 예외는 IllegalArgumentException으로 호출자가 인수로 부적절한 값을 넘길 때 던지는 예외이다.

메서드가 던지는 모든 예외를 잘못된 인수나 상태라고 뭉뚱그릴 수도 있지만 특수한 일부는 따로 구분해서 쓰는게 보통이다.

1. null 값을 허용하지 않는 메서드에 null을 건네면 관례상 IllegalArgumentException이 아닌 NullpointerException을 던진다.
2. 어떤 시퀀스의 허용 범위를 넘는 값을 건넬 때도 IllegalArgumentException이 아닌IndexOutOfBoundsException을 던진다.
3. ConcurrentModificationException은 단일 스레드에서 사용하려고 설계한 객체를 여러 스레드가 동시에 수정하려 할 때 던진다.
4. UnsupportedOperationException으로 클라이언트가 요청한 동작을 대상 객체가 지원하지 않을 때 던진다.

Exception, RuntimeException, Throwable, Error는 직접 재사용하지 말자

• 위 클래스는 추상 클래스라고 생각하고 다른 예외들의 상위 클래스이므로 포괄하는 클래스라서 안정적으로 테스트할 수 없다.

상황에 부합하다면 항상 표준 예외를 재사용하자.

• API 문서를 참고해 그 예외가 어떤 상황에서 던져지는지 꼭 확인해야 한다.
• 예외의 이름뿐 아니라 예외가 던져지는 맥락도 부합할 때만 재사용한다.
• 더 많은 정보를 원한다면 표준 예외를 확장해도 좋다. 단, 예외는 직렬화할 수 있다는 사실을 기억하자(직렬화에는 많은 부담이 따르니) 나만의 예외를 새로 만들지 않아야 할 근거는 충분하다.

⇒ IllegalArgumentException(아이템49)

인수 값이 무엇이었든 어차피 실패했을거라면 IllegalStateException을, 그렇지 않으면 IllegalArgumentException을 던지자.

---

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

상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외를 바꿔 던져야 한다.

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

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

• 예외 번역의 예시이다.

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

• AbstractSequentialList에서 수행하는 예외 번역의 예로 List 인터페이스의 골격 구현이다.
• 예외 번역할 때, 저수준 예외가 디버깅에 도움이 된다면 예외 인쇄를 사용하는 게 좋다.
  • 예외 인쇄란 문제의 근본 원인인 저수준 예외를 고수준 예외에 실어 보내는 방식으로 별도의 접근자 메서드(Throwable의 getCause 메서드)를 통해 필요하면 언제든 저수준 예외를 꺼내 볼 수 있다.

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

• 예외 연쇄 예시로 cause로 저 수준 예외를 인자로 준다.

class HigherLevelExcetion extends Exception { // 예외 연쇄용 생성자
    HigherLevelException(Throwable cause) {
        super(cause);
    }
}

• 대부분의 표준 예외는 예외 연쇄용 생성자를 갖고 그렇지 않은 예외라도 Throwable의 initCause 메서드를 이용해 '원인'을 직접 못박을 수 있다.
• 예외 연쇄는 문제의 원인을(getCause 메서드로) 프로그램에서 접근할 수 있게 해주며, 원인과 고수준 예외의 스택 추적 정보를 잘 통합해준다.

무턱대고 예외를 전파하는 것보다야 예외 번역이 우수한 방법이지만, 그렇다고 남용해서는 곤란하다.

• 가능하다면 저수준 메서드가 반드시 성공하도록 하여 아래 계층에서는 예외가 발생하지 않도록 하는 것이 최선이다.
• 상위 계층 메서드의 매개변수 값을 아래 계층 메서드로 건네기 전에 미리 검사하는 방법으로 목적을 달성할 수 있다.
• 차선책으로 아래 계층에서의 예외를 피할 수 없다면, 상위 계층에서 그 예외를 조용히 처리하여 문제를 API 호출자에게까지 전파하지 않는 방법이 있다.
• 발생한 예외는 java.util.logging 같은 적절한 로깅 기능을 활용하여 기록해두면 좋다.

⇒ AbstractSequentialList(아이템20), 고수준 예외를 던지면서 근분 원인도 알려준다(아이템75)

아래 계층 예외를 예방하거나 스스로 처리할 수 없고, 그 예외를 상위 계층에 그대로 노출하기 곤란하다면 예외 번역을 사용하라. 이때 예외 연쇄를 이용하면 상위 계층에는 맥락에 어울리는 고수준 예외를 던지면서 근본 우너인도 함께 알려주어 오류를 분석하기에 좋다.

---

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

메서드에서 던지는 예외는 메서드가 올바르게 사용되는 중요한 정보이므로 던지는 예외 하나하나를 문서화 하는데 충분한 시간을 쏟아야 한다.

문서화 해야 하는 경우

1. 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @Throws 태그를 사용하여 정확히 문서화하자.
   • 공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가자.
   • 극단적인 예로 Excetion이나 Throwable을 던진다고 선언해서는 안 되며 유일한 예외 메서드는 main뿐이다.
2. 비검사 예외도 검사 예외처럼 정성껏 문서화해두면 좋다.
   • 잘 정비된 비검사 예외 문서는 사실상 그 메서드를 성공적으로 수행햐기 위한 전제조건이 된다.
3. public 메서드라면 필요한 전제조건을 문서화해야 하며, 그 수단으로 가장 좋은 것이 바로 비검사 예외들을 문서화하는 것이다.
   1. 발생 가능한 비검사 예외를 문서로 남기는 일은 인터페이스 메서드에서 특히 중요하다.
4. 메서드가 던질 수 있는 예외를 각각 @throws 태그로 문서화하되, 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자.
5. 검사냐 비검사냐에 따라 API 사용자가 해야 할 일이 달라지므로 확실히 구분하는게 좋다.
   1. 자바독 유틸리티는 메서드 선언의 throws 절에 등장하고 메서드 주석의 @throws 태그에도 명시한 예외와 @throws 태그에만 명시한 예외를 시각적으로 구분해준다.

비검사 예외를 현실적으로 문서화가 불가능한 경우

• 클래스를 수정하면서 새로운 비검사 예외를 던지게 되어도 소스 호환성과 바이너리 호환성이 그대로 유지된다는게 가장 큰 이유다.
• 예를 들어 다른 사람이 작성한 클래스를 사용하는 메서드가 있는데 발생 가능한 모든 예외를 공들여 문서화 했지만 후에 이 외부 클래스가 새로운 비검사 예외를 던지게 수정한다면, 아무 수정도 하지 않은 우리 메서드는 문서에 언급도지 않는 새로운 비검사 예외를 전파하게 된다.

한 클래스에 정의된 많은 메서드가 같은 이유로 같은 예외를 던진다면 그 예외를 (각각의 메서드가 아닌) 클래스 설명에 추가하는 방법도 있다.

• NullpointerException이 가장 흔한 사례로 "이 클래스의 모든 메서드는 인수를 null이 넘어오면 NullPointerException을 던진다"라고 적어도 좋다.

메서드가 던진 가능성이 있는 모든 예외를 문서화하라. 검사 예외든 비검사 예외든, 추상 메서드든 구체 메서드든 모두 마찬가지다. 문서화에는 자바독 @throws 태그를 사용하면 되고 검사 예외만 메서드 선언의 throws문에 일일이 선언하고 비검사 예외 메서드 선언에는 기입하지 말자. 발생 가능한 예외를 문서로 남기지 않으면 다른 사람이 그 클래스나 인터페이스를 효과적으로 사용하기 어렵거나 심지어 불가능할 수도 있다.

---

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

예외를 잡지 하면 자바 시스템은 예외의 스택 추적 정보를 자동으로 출력하고 예외 객체의 toString메서드를 호출해 얻은 문자열로, 예외의 클래스 이름 뒤에 상세 메시지가 붙은 형태이다.

실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 한다.

• 사후 분석을 위해 실패 순간의 상황을 정확히 포착해 예외의 상세 메시지에 담아야 한다.
• 상세 미시지에 비밀번호나 암호 키 같은 정보까지 담아서는 안 된다.
• 문서와 소스코드에서 얻을 수 있는 정보는 길게 늘어놔봐야 군더더기가 될 뿐이다.
• 예외의 상세 메시지와 최종 사용자에게 보여줄 오류 메시지를 혼동해서는 안 된다.
  • 최종 사용자에게는 친절한 안내 메시지를 보여줘야 하는 반면 예외 메시지는 가독성보다는 담긴 내용이 훨씬 중요하다.

예외는 실패와 관련한 정보를 얻을 수 있는 접근자 메서드를 적절히 제공하는 것이 좋다.

• 포착한 실패 정보는 예외 상황을 복구하는데 유용할 수 있으므로 접근자 메서드는 비검사 예외보다는 검사 예외에서 더 빛을 발한다.
• 'toString이 반환 값에 포함된 정보를 얻어올 수 있는 API를 제공하자'라는 일반 원칙을 따른다는 관점에서, 비검사 예외도 상세 정보를 알려주는 접근자 메서들르 제공하라고 권하고 싶다.

⇒ 예외 하나하나를 문서화하는데(아이템56), 일반적으로 프로그래밍 오류(아이템70), public 메서드라면 필요한 전제조건을 문서화해야 하며(아이템56)

예외 상세 메시지에는 실패 관련 정보를 담고 코드에서 얻을 수 있는 정보는 피하자.

---

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

일반화해 이야기하면, 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다.

• 이러한 특성을 실패 원자적이라고 한다.
• 검사 예외를 던진 경우라면 호출자가 오류 상태를 복구할 수 있을테니 더 유용하다.

메서드를 실패 원자적으로 만드는 방법

1. 불변 객체로 설계하면 태생적으로 실패 원자적이므로 메서드가 실패하면 새로운 객체가 만들어지지는 않을 수 있으나 기존 객체가 불안정한 상태에 빠지는 일은 결코 없다.
2. 가변 객체의 메서드를 실패 원자적으로 만드는 방법은 작업 수행 전에 매개변수의 유효성을 검사하는 방법이며 객체의 내부 상태를 변경하기 전에 잠재적 예외의 가능성을 대부분을 걸러낼 수 있다.

    public Object pop() {
        if (size == 0) 
            throw new EmptyStackException();
        Object result = elements[--size];
        elements[size] = null; // 다 쓴 참조 해제
        return result;
    }

3. 객체의 임시 복사본에서 작업을 수행한다 다음 작업이 성공적으로 완료되면 원래 객체와 교체하는 방법으로 데이터를 임시 자료구조에 저장해 작업하는 게 더 빠를 때 적용하기 좋은 방식이다.
   • 성능을 높이고자 취한 결정이지만, 기존 원본은 변하지 않는 효과를 덤으로 얻게 된다.
4. 작업 도중 발생하는 실패를 가로채는 복구 코드를 작성하여 작업 전 상태로 되돌리는 방법이다.
   • 주로 (디스크 기반의) 내구성을 보장해야 하는 자료구조에 쓰이는데, 자주 쓰이는 방법은 아니다.

실패 원자성을 보장할 수 없는 경우

• 두 스레드가 동기화 없이 같은 객체를 동시에 수정한다면 객체의 일관성이 깨질 수 있다.
• 실패 원자적으로 만들 수 있어도 항상 그렇게 해야 하는건 아닌데 실패 원자성을 달성하기 위핸 비용이나 복잡도가 아주 큰 연산에서 해당한다.
• 문제가 무엇인지 알고 나면 실패 원자성을 공짜로 얻을 수 있는 경우가 많다.

⇒ 불변객체(아이템17), 매개변수의 유효성 검사(아이템49), 추상화 수준(아이템73)

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

---

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

API 설계자가 메서드 선언에 예외를 명시하는 까닭은, 그 메서드를 사용할 때 적절한 조치를 취해달라고 말하는 것으로 예외를 무시하지 말자.

try {
    ...
} catch (SomeException e) {
}

• catch 블록을 비워두면 예외가 무시되는데 아주 의심스러운 코드이다.
• catch 블록을 비워두면 예외가 존재할 이유가 없어진다.
• 예외를 무시하는 건 화재경보를 무시하는 수준을 넘어 아예 꺼버려, 다른 누구도 화재가 발생했음을 알지 못하게 하는 것과 같다.
• 혹시나 같은 예외가 자주 발생한다면 조사해보는 것이 좋으니 로그를 남기는 방법도 있다.
• 예외를 무시하기로 했다면 catch 블록 안에 그렇게 한 이유를 주석으로 남기고 예외 변수의 이름도 ignored로 바꿔놓도록 하자.

Future<Integer> f = exec.submit(planarMap::chromaticNumber);
int numColors = 4; // 기본값. 어떤 지도라도 이 값이면 충분하다.
try {
    numColor = f.get(1L, TimeUnit.SECONDS);
} catch (TimeoutException | ExecutionException ignored) {
    // 기본 값을 사용한다.(색상 수를 최소화하면 좋지만, 필수는 아니다.
}

검사와 비검사 예외에 똑같이 적용되며 예측할 수 있는 있는 예외 상황이든 프로그래밍 오류든, 빈 catch 블록으로 못 본척 지나치면 프로그램은 오류를 내재한 채 동작한다.
예외를 적절히 처리하면 오류를 완전히 피할 수도 있다. 무시하지 않고 바깥으로 전파되게만 돠둬도 최소한 디버깅 정보를 남긴 채 프로그램이 신속히 중단되게는 할 수 있다.

---