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

■ 검사 예외와 비검사 예외 / 에러

자바는 문제 상황을 알리는 타입으로(throwable)으로 검사 에외, 런타임 예외, 에러 이렇게 3가지를 제공한다. 예외 종류와 관련해서는 아래 링크를 참고하자.

 

https://insight-bgh.tistory.com/24?category=857504

 

호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라. 이것이 검사와 비검사 예외를 구분하는 기본 규칙이다. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아서 처리하거나 더 바깥으로 전파하도록 강제한다.

 

비검사 throwable은 두 가지로, 바로 런타임 예외와 에러다. 이 둘은 프로그램에서 잡을 필요가 없거나 보통 잡지 말아야한다. 이런 throwable을 잡지 않은 스레드는 적절한 오류 메시지를 내뱉으며 중단된다.

 

프로그램 오류를 나타날 때는 런타임 예외를 사용하자. 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.

 

에러는 보통 JVM 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다. 자바 언어 명세가 요구하는 것은 아니지만 업계에 널리 퍼진 규약은 Error 클래스를 상속해 하위 클래스를 만드는 일은 자제한다. 즉, 우리가 구현하는 비검사는 모두 RuntimeException의 하위 클래스여야 한다.

 

검사 예외는 일반적으로 복구할 수 있는 조건일 때 발생한다. 따라서 호출자가 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다. 예를 들어서 쇼핑몰에서 물건을 구입하려는 데 카드 잔고가 부족하여 검사 예외가 발생했다고 해보자. 그렇다면 이 예외는 잔고가 얼마나 부족하지를 알려주는 접근자 메서드를 제공해야 한다.

 

■ 핵심 정리

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