Item70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라!
Intro
- 자바는 문제 상황을 알리는 타입(throwable)으로
검사 예외,런타임 예외,에러, 이렇게 세 가지를 제공한다. - 언제 무엇을 사용해야 하는지 헷갈리지 않도록 참고할만한 좋은 지침들을 소개하는 아이템이다.
지침
1. 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라
- 검사와 비검사 예외를 구분하는 기본 규칙이다.
- 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다.
- API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한 것이다.
- 검사 예외는 일반적으로 복구 가능한 조건일 때 발생한다. 따라서 예외 상황에서 벗어날 수 있는 경우이므로, 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다.
2. 프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자
비검사 throwable
- 비검사 throwable은 두 가지로 나뉜다. 바로 런타임 예외와 에러다.
- 둘 다 동작 측면에서는 다르지 않다. 이 두 가지는 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다.
- 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구 불가하거나 실행에 있어 잃는 것이 더 많다는 것을 의미하기 때문이다.
- 이러한 throwable을 잡지 않은 스레드는 적절한 오류 메시지를 내뱉으며 중단된다.
- 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.
- 전제조건 위배는 클라이언트가 해당 API 명세에 기록된 제약을 지키지 못했다는 것을 말한다.
- 예를 들어 배열의 인덱스는
0 ~ 배열크기-1의 제약을 갖는데, 이를 어기면ArrayIndexOutOfBoundsException런타임 예외가 발생한다.
복구 가능 상황 vs 프로그래밍 오류
- 배열 할당 시의 자원 고갈을 예를 들어보자.
- 말도 안 되는 크기의 배열을 할당해 생긴 프로그램 오류이거나 진짜 자원이 부족해 발생한 문제일 수 있다.
- 자원이 일시적으로만 부족한 것이거나 수요가 순간적으로 몰린 것이라면 충분히 복구 가능할 것이다.
- 만약, 복구가 가능하다고 믿는다면 API 설계자는 검사 예외를 사용할 것이고, 그렇지 않다면 런타임 예외를 사용할 것이다.
- 확신이 어렵다면 비검사 예외를 사용하는 편이 낫다.
3. 비검사 throwable은 모두 RuntimeException의 하위 클래스로 구현해야 한다.
- 에러는 보통 자원 부족, 불변식 깨짐 등의 이유로 JVM이 더 이상 수행을 지속할 수 없는 상황을 나타낼 때 사용한다.
- 자바 언어 명세가 요구하는 것은 아니지만 업계 표준이니, Error 클래스를 상속해 하위 클래스를 만드는 일은 하지 말자.
- 이를 다시 말하면, 구현하고자 하는 throwable은 모두 런타임 예외의 하위 클래스로 구현해야 한다는 것이다.
- Error는 상속 뿐만 아니라, throw 문으로 직접 던지는 일도 없어야 한다. (AssertionError는 제외)
Exception, RuntimeException, Error를 상속하지 않는 throwable
- 암묵적으로 일반적인 검사 예외처럼 다룬다.
- 이로울 게 없으니 절대 사용하지 말자!
- throwable은 정상적인 검사 예외보다 나을 게 하나도 없으면서 API 사용자를 헷갈리게 할 뿐이다.
핵심 정리
- 복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자.
- 확실하지 않다면 비검사 예외를 던지자.
- 검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지도 말자.
- 검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자.
Comments powered by Disqus.