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

문제상황 권고 타입

자바는 문제 상황을 알리는 타입(throwable)으로 아래 3가지를 제공한다.

1) 검사 예외
2) 런타임 예외
3) 에러

위 3가지를 어떤 상황에서 선택해서 사용해야할지 헷갈린다. 이에 도움이 될 수 있는 지침을 살펴보자.

 

 

검사 예외

1) 호출하는 쪽에서 복구하리라 여겨지는 상황일 경우

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

 

API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한 것이다. 호출한 쪽에게 책임을 묻는 경우다. 

 

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

 

 

비검사 예외

비검사 throwable은 2가지로, 런타임 에러와 에러가 있다. 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야한다. 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다. 이런 throwable을 잡지 않은 스레드는 적절한 오류 메시지를 내뱉으며 중단된다. 

 

1) 런타임 예외

프로그래밍 오류를 나타낼 경우 사용하자. 런타임 예외의 대부분은 전제 조건을 만족하지 못했을 경우 발생한다. 이는 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 뜻이다. 

 

예시

배열의 인덱스는 0 ~ 배열크기 -1 사이의 값인데, 이 전제조건이 지켜지지 않을 경우 ArrayIndexOutOfBoundsException 이 발생한다.

 

상황

프로그램에서 발생한 오류는 아래의 오류 중 확실하게 구분하기 어렵다.

- 말도 안되는 크기의 배열을 할당하여 발생한 오류 (일 수도 있고)

- 진짜로 자원이 부족해서 발생한 오류 (일 수도 있다)

 

만약 자원이 일시적으로만 부족하거나 수요가 순간적으로만 몰린 것이라면 충분히 복구할 수 있는 상황이다. 해당 자원 고갈 상황이 복구될 수 있는 것인지는 API 설계자가 판단할 문제이며, 여기서 검사 예외/비검사 예외를 선택할 수 있다.

 

1) 복구가 가능하다고 판단된다. -> 검사 예외 (체크하자)

2) 복구가 불가능하다고 판단된다. -> 비검사 예외

3) 판단하기 어렵다. -> 비검사 예외를 선택하는 편이 낫다.

 

2) 에러

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

 

우리가 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다. Error는 상속하지도 말고, throw문으로 던지지도 말자.

 

Exception, RuntimeException, Error을 상속하지 않는 throwable 을 만들 수 있지만, 이런 throwable은 절대 만들지도, 사용하지도말자.