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

[fairsun]

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

• 검사/비검사 예외를 구분하는 기본 규칙

검사 예외(checked exception)

• try/catch 처리
• throw : 더 바깥으로 전파하도록 강제
• checked exception 각각은 메서드를 호출했을때 발생할 수 있는 유력한 결과임을 API사용자에게 알려주는 것.

비검사 예외(unchecked exception)

• 런타임 예외(runtime exception)와 에러(Error)
• 프로그램에서 잡을 필요가 없거나 혹은 통상적으로는 잡지 말아야한다.
• 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻.
• throwable을 잡지 않은 스레드는 적절한 오류 메세지를 내뱉으며 중단된다.
  • ex> NullPointException, ArrayIndexOutOfBoundsException

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

• 전제조건 위배 시 발생 : ArrayIndexOutOfBoundsException
• 복구할 수 있는 상황인지 프로그래밍 오류인지가 항상 명확히 구분되지 않는다.
  • 말도 안되는 크기의 배열을 할당해 생긴 프로그래밍 오류 or 자원 부족
• 복구 가능하다고 믿는다면 검사 예외(checked exception), 아니면 런타임 예외(runtime exception)
• 확인하기 어렵다면 비검사 예외(unchecked exception) -> why? #71

에러(Error)

• 보통 JVM이 자원이 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다.
• Error 클래스를 상속해 하위 클래스는 만드는 일은 자제하기 바란다. (업계에 널리 퍼진 규약)
• 즉, 비검사 예외(unchecked exception)는 모두 RuntimeException의 하위 클래스여야 한다.
• Error는 상속도 하지말고 throw문으로 직접 던지는 일도 없어야한다. (AssertionError는 예외)

Exception, RuntionException, Error를 상속하지 않는 throwable을 만들 수도 있지만 절대로 사용하지 말자.

• throwable은 정상적인 검사 예외(checked exception)보다 나을게 없으면서 API사용자를 헷갈리게 할 뿐이다.

검사 예외(checked exception)라면 복구에 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다.

• throwable 클랙스는 대부분 오류 메시지 포맷을 상세히 기술하지 않는데, 이는 JVM이나 릴리스에 따라 포맷이 달라질 수 있다는 뜻이다.

• 75 에서 자세히 다룬다.

핵심 정리

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