예외

예외는 진짜 예외 상황에만 사용하라

 - 예외는 오직 예외 상황에서만 써야 한다. 절대로 일상적인 제어 흐름용으로 쓰여선 안 된다.

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

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

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

 - 프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자.

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

 - 검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지 말자.

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

필요 없는 검사 예외 사용은 피하라

 - 꼭 필요한 곳에만 사용하자.

 - API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자.

 - 복구가 가능하고 호출자가 그 처리를 해주길 바란다면, 우선 Optional을 반환해도 될지 고민하자.

 - Optional만으로 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.

표준 예외를 사용하라

 - Execption, RuntimeException, Throwable, Error는 직접 재사용하지 말자.

 - 널리 재사용되는 예외

예외	주요 쓰임
IllegalArgumentException	허용하지 않는 값이 인수로 건네졌을 때(null은 따로 NullPointerException으로 처리)
IllegalStateException	객체가 메서드를 수행하기에 적절하지 않은 상태일 때
NullPointerException	null을 허용하지 않는 메서드에 null이 건네졌을 때
IndexOutOfBoundsException	인덱스가 범위를 넘어섰을 때
ConcurrentModificationException	허용하지 않는 동시 수정이 발견됐을 때
UnsupportOperationException	호출한 메서드를 지원하지 않을 때

추상화 수준에 맞는 예외를 던져라

 - 예외 번역(exception translation) : 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다.

 - 무턱대고 예외를 전파하는 것보다 예외 번역이 우수한 방법이지만, 남용하지는 말자.

 - 예외 연쇄를 이용하면 상위 계층에는 맥락에 어울리는 고수준 예외를 던지면서 근본 원인도 함께 알려주면 오류를 분석하기에 좋다.

try {

...

} catch (LowerLevelException e) {

throw new HigherLevelException(..., e);

}

메서드가 던지는 모든 예외를 문서화하라

 - 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자.

 - 메서드가 던질 수 있는 예외를 각각 @throws 태그로 문서화하되, 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자.

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

예외의 상세 메시지에 실패 관련 정보를 담아라

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

가능한 한 실패 원자적으로 만들라

 - 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다.

예외를 무시하지 말라

 - catch 블록을 비워두면 예외가 존재할 이유가 없어진다.

 - 예외를 무시하기로 했다면 catch 블록 안에 그렇게 결정한 이유를 주석으로 남기고 예외 변수의 이름도 ignored로 바꿔놓도록 하자.