[이펙티브자바] Item 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

 

throwable은 사용하지 말자.

 

자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러를 제공한다.

언제나 100% 명확한 건 아니지만 따르는 지침들이 있다.

 

📢 검사예외

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

 

검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다.

즉, API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한다.

 

비검사 throwable은 두 가지로, 바로 런타임 예외와 에러다.

둘 다 동작 측면에서는 다르지 않다.

이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다.

즉, 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다.

 

검사 예외는 일반적으로 복구할 수 있는 조건일 때 발생한다.

따라서 호출자가 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다.

 

💥 런타임 예외

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

런타임 예외의 대부분은 전제조건(해당 API의 명세에 기록된 제약을 지키지 못한 것)을 만족하지 못했을 때 발생한다.

 

쉽게 정리하자면, 

복구 가능하다고 믿는다면 검사 예외를,

그렇지 않다면 런타임 예외를,

확신하기 어렵다면 비검사 예외를 선택하는 것이 낫다.

 

🎈 에러

에러는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다.

따라서 여러분이 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.

(Error 클래스를 상속해 하위 클래스를 만드는 일은 하지 마라)

Error는 상속하지 말아야 할 뿐 아니라, Throw 문으로 직접 던지는 일도 없어야 한다.

 

🔎 throwable

Exception, RuntimeException, Error를 상속하지 않는 throwable을 만들 수도 있다. 

하지만 이런 throwable은 이로울 게 전혀 없으니 절대로 사용하지 말자.

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

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

따라서 메시지 문자열을 파싱 해 얻은 코드는 깨지기 쉽고 다른 환경에서 동작하지 않을 수 있다.

 

💡정리

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