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

💥 개요

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

이것이 검사와 비검사 예외를 구분하는 기본 규칙이다.

검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려준다.

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

 

💡 비검사 throwable 2가지

런타임 예외와 에러는 둘 다 동작 측면에서는 다르지 않다. 이 둘은 잡을 필요가 없거나 혹은 잡지 말아야 한다.

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

프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자. 우리가 구현하는 비검사 thorwable은 모두 RuntimeException의 하위 클래스여야 한다. 

Exception, RuntimeException, Error를 상속하지 않는 throwable을 만들수도 있다. 하지만 이로울 게 없으니 절대 사용하지말자

정상적인 검사 예외보다 나을게 하나도 없으며 API 사용자를 헷갈리게 한다.

 

⚠️ 검사 예외

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

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

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

 

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