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

EFFECTIVE JAVA(이펙티브 자바)

 

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다.

---

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

 

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

 

검사 예외

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

 

 

비검사 예외

• 비검사 예외(throwable)은 두 가지로, 바로 런타임 예외와 에러다.
• 둘 다 동작 측면에서는 다르지 않다.
• 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다.
• 프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자
• 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.
• 복구 가능하다고 믿는다면 검사 예외를, 그렇지 않다면 런타임 예외를 사용하자. 확신하기 어렵다면 아마도 비검사 예외를 선택하는 편이 낫다. (아이템 71)
• 에러는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낸다.
• 개발자가 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.
• Error는 상속하지 말아야 할 뿐 아니라, throw 문으로 직접 던지는 일도 없어야 한다. (AssertionError 예외)

 

 

정리

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