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

throwable - 절대 사용하지 말자

암묵적으로 일반적인 검사 예외처럼 다룬다.

개발자들이 가끔 잊곤 하는 점은, 예외 역시 어떤 메서드라도 정의할 수 있는 완벽한 객체라는 점이다. 예외의 메서드(printStackTrace 등)는 예외를 일으킨 상황에 대한 정보를 전달해준다. 예외의 메서드를 통해 실패 관련 정보를 자세하게 담아야 한다.

그런데, throwable 클래스들은 대부분 오류 메시지 포맷이 상세하지 않으므로 JVM이나 릴리스에 따라 포맷이 달라질 수 있다.

또한 throwable은 정상적인 검사 예외보다 나을게 하나도 없으면서 API 사용자를 헷갈리게 할 뿐이니 책에서는 절대 사용하지 말라고 말하고 있다.

검사 예외(checked Exception) - 호출하는 쪽에서 복구

Exception 클래스에서 RuntimeException을 제외한 다른 클래스들이 검사 예외이다.

개발자가 충분히 복구할 수 있는 상황이라 여겨지면 던지게 된다.

메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려준다.

throwable에서 말한 것 처럼, 예외의 메서드를 통해 실패 관련 정보를 담아야 한다.(item 75에 계속)

예를 들어, 쇼핑몰에서 물건을 구입하려는데 카드 잔고가 부족해 검사 예외가 발생했다. 그렇다면 이 예외는 잔고가 얼마나 부족한지를 알려주는 접근자 메서드를 제공해야 한다.

에러 - 던지거나, 상속받지 말자

복구가 불가능하거나, 더 실행해봐야 득보다는 실이 많다는 뜻으로, 프로그램이 적절한 오류메시지를 내뱉으며 중단된다.

JVM 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황에 사용된다.

그리고 자바 언어 명세가 요구하는 것은 아니지만 업계에 퍼진 약속으로 Error 클래스를 상속한 하위 클래스를 만들거나 throw로 던지지도 말자.

즉, 비검사 예외를 만들 때는 RuntimeException을 상속받아야 한다.

RuntimeException - 프로그래밍 오류

복구가 불가능하거나, 더 실행해봐야 득보다는 실이 많다는 뜻으로, 프로그램이 적절한 오류메시지를 내뱉으며 중단된다.

대부분의 런타임예외는 전제조건을 만족하지 못했을 때 발생한다.

다만 문제가 있다면 복구할 수 있는 상황인지, 프로그래밍 오류인지가 항상 명확히 구분되지는 않는다는 점이다.

예를 들어, 자원 고갈은 말도 안 되는 크기의 배열을 할당해 생긴 프로그래밍 오류일 수도 있고, 진짜로 자원이 부족해서 발생한 문제일 수도 있다.

만약 자원이 일시적으로 부족한 상황이라면 충분히 복구될 수 있을 것이다.

그러므로 복구 가능하다고 믿는다면 검사 예외를, 그렇지 않다면 RuntimeException을 사용하자.

정리

개발자가 복구할 수 있는 문제는 검사 예외로,

프로그래밍 오류는 런타임 예외로 던진다.

throwable과 Error는 상속받거나, 던지지 말자.