요약
•
문제 상황이 발생했을 때, 복구가 가능하다고 여겨지면 검사 예외를 사용하자.
•
문제 상황의 복구가 불가능하고 프로그래밍의 오류를 나타낼 때는 런타임 예외를 사용하자.
•
직접 구현하는 비검사 throwable은 모두 RunTimeException의 하위 클래스로 만들어, 직접 에러를 사용하는걸 피하자.
throwable 예외
•
자바에는 문제 상황을 알리는 타입(throwable)으로 검사 예외가 있고, 비검사 throwable로 런타임 예외, 에러가 있다.
•
검사 예외는 프로그램에서 해당 검사하여 해당 예외를 발생 시키는 것이고, 비검사 throwable은 둘 모두 프로그램에서 잡을 필요가 없거나 통상적으로 잡지 말아야하는 문제 상황이다.
검사 예외
•
검사와 비검사 예외를 구분하는 기본 규칙은 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하는 것이다.
•
검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나, 더 바깥으로 전파하도록 강제된다. 따라서 메서드 선언에 throw로 포함된 검사 예외는 해당 메서드를 호출 했을 때 발생할 수 있다는 것을 알려주어, 사용자에게 그 상황에 대한 대처를 요구하는 것이다.
런타임 예외
•
프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자. 런타임 예외의 대부분은 전제조건을 만족시키지 못했을 때 발생하는데, 이는 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 않았다는 뜻이다.
•
하나의 예시로 배열의 인덱스는 0부터 ‘배열 크기 -1’ 사이의 값이어야 한다. ArrayIndexOutOfBoundsException은 이 전제조건이 지켜지지 않았다는 의미이다.
•
이러한 오류가 발생했을 때 복구가 가능한 상황인지 불가능한 상황인지 명확히 구분되지 않는 경우가 많다. 복구가 가능하다면 검사 예외를, 그렇지 않으면 런타임 예외를 사용하자. 복구에 대해 확신하기 어렵다면 비검사 예외를 선택하는 편이 좋다.
에러
•
에러는 JVM에서의 자원 부족, 불변식 깨짐 등 더 이상 작업의 수행을 이어나갈 수 없는 상황일 때 사용한다.
•
그러한 이유로 우리가 Error 클래스를 상속해 하위 클래스를 만드는 것은 자제해야 한다. 다시 말해, AssertionError를 제외하고 직접 구현하는 비검사 throwable은 모두 RunTimeException의 하위 클래스여야 한다는 것이다.