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

 호출하는 쪽에서 복구 할 수 있는 상황이라면 검사 예외를 사용하자

---

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

 

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

---

비검사 throwable은 두 가지로 런타임 예외와 에러다. 비검사 예외나 에러는 복구가 불가능한 경우나 더 실행해봐야 득보다는 실이 많은 경우에 사용한다.

 

 

여기서, 런타임 예외의 대부분은 단순히 클라이언트가 API 명세를 따르지 않아서 일어나는 예외이다.

 

위 상황에 대한 예는 ArrayIndexOutOfBoundsException 으로 쉽게 설명이 가능하다. 배열의 인덱스는 적어도 0에서 시작하고 '배열 길이 -1' 사이여야 한다. 하지만, 이때 ArrayIndexOutOfBoundsException이 발생한다면 위의 전제조건이 지켜지지 않아서 이다.

---

하지만, 항상 위의 조건을 지켜서 쓸 수 있는 상황인지 인지하기 어려운 경우가 존재한다.

 

예로, 자원 고갈은 말도 안되는 크기의 배열을 할당해 생긴 프로그래밍 오류 일 수 있고 진짜로 자원이 부족해서 생긴 문제 일 수도 있다. 이때, 전자의 경우는 프로그래밍 오류로 런타임 예외를 하여야한다. 후자의 경우는 검사 예외를 사용해서 복구 할 수 있는 오류를 내어야 한다.

 

 따라서, API 설계자의 판단에 따라서 검사 예외 또는 런타임 예외를 사용하자.

 

에러

---

에러는 보통 JVM 자원의 부족, 불변식 깨짐 등 더 이상 수행을 할 수 없는 경우에 사용한다. 이는 업계 표준으로 Error 클래스를 상속해서 하위 클래스를 만드는 일을 자재를 부탁한다.

 

그래서, 우리가 구현하는 비검사 throwble은 모두 RuntimeException의 하위 클래스여야 한다. (Error는 하위 클래스로 상속하는 것을 하지 않기로 업계 표준으로 정하였기에...)

 

Error는 상속하지 말아야할 뿐 아니라, throw 문을 직접 던지는 일도 없어야한다.(AssertionError는 예외)

Exception, RuntimeException, Error를 상속하지 않은 throwble을 만들 수 있는데 이런, throwable은 이로울 게 없으니 절대 사용하지 말아라.

 

위와 같은 throwable은 기존의 예외보다 나을 게 없으며 API 사용자를 헷갈리게 할 뿐이다.

 

예외의 메서드

---

예외의 메서드는 주로 그 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는데 쓰인다. 그러나 throwable 클래스들은 대부분 오류 메시지 포맷을 상세히 기술하지 않는다. 이것은, JVM이나 릴리스에 따라 포맷이 달라질 수 있다는 뜻이다. (메시지 문자열 파싱했더니 다른 환경에서는 포멧이 달라져서 깨질 수가 있다는 말) 

 

그래서 해당 메서드는 필요한 정보를 알려주는 메서드로 쓰여야 하는데 해당 주제는 아이템 75에서 다룬다고 합니다.

 

 

핵심정리

검사 예외 : 복구 할 수 있는 상황에서 사용

런타임 예외(비검사 예외) : 복구 불가능, 확실하지 않은 경우 사용

비검사 예외도 아닌 검사 예외도 아닌 throwable은 사용하지 말자.
검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자 (Item.75)