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

[Mingadinga]

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

검사 예외 vs 런타임 예외 vs 에러

셋 다 문제 상황을 알리는 타입(throwabe)이다.

Error

• 자원 부족, 불변식 깨짐 등과 같이 시스템이 비정상적인 경우 프로그램 수행을 계속할 수 없는 상황을 나타낸다.
• 주로 JVM이 발생시키기 때문에 애플리케이션 코드에서 잡아서는 안되며, 잡아서 대응할 방법도 없다. 에러 처리는 당연히 생략한다.
• Error 클래스를 상속해 하위 클래스를 만드는 일은 하지 말아라.

Checked Exception

• 클라이언트가 복구 가능하다고 여겨지는 상황에서 사용하는 예외이다.
• 검사 예외를 던지면 클라이언트는 try 블록으로 예외를 잡거나 예외를 강제로 전파해야한다. 즉, 클라이언트가 검사 예외를 반드시 복구해야한다.
• API 설계자가 클라이언트에게 검사 예외를 던졌다는 것은 그 상황을 회복할 것을 요구한 것이다. 클라이언트가 예외를 잡기만 하고 별다른 조치를 취하지 않을 수도 있지만, 이는 보통 좋지 않은 생각이다.

UnChecked Exception

• 검사 예외와 달리 잡지 않아도 된다. 비검사 예외를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다. 예외를 잡을 필요도, 강제로 전파할 필요도 없다. 잡히지 않은 비검사 예외는 해당 스레드를 종료시키고 동작을 끝낸다.
• 비검사 예외는 프로그래밍 오류를 나타낼 때 많이 사용한다. 대부분은 전제조건을 만족하지 못했을 때 발생하는데, 예를 들어 배열의 유효한 범위를 벗어나 접근을 시도한 경우 던지는 ArrayIndexOutOfBoundsException이 그 예이다.

Error vs Checked Exception vs UnChecked Exception

• 복구할 수 있는 상황인지 프로그래밍 오류인지 항상 명확히 구분되지는 않는다.
• 예시 : 자원 고갈 상황
• 복구 가능한 원인 : 말도 안 되는 크기의 배열을 할당해서 자원이 일시적으로 부족함
• 복구 불가능한 원인 : 시스템에 진짜 자원이 부족함(Error, 잡지 말아야함)
• 따라서 복구 가능하다고 믿는다면 검사 예외를, 그렇지 않다면 런타임 예외를 사용한다. 확신하기 어렵다면 비검사 예외를 사용하는 것이 낫다. 검사 예외가 주는 부담 때문이다.

Throwable

Exception, RuntimeException, Error를 상속하지 않는 throwable을 만들 수도 있지만, 이로울 게 없으니 절대 사용하지 말자!!!

검사 예외에는 예외 메서드도 작성하자

예외도 완전한 객체이며, 예외의 메소드는 주로 그 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는데 쓰인다. 만약 이런 메서드가 없다면 클라이언트가 직접 예외 스택에서 문자열을 파싱해 오류 원인을 알아야 하는데, throwable의 오류 메시지 포맷은 자바 버전에 따라 쉽게 바뀐다. 따라서 문자열 파싱 방식은 깨지기 쉬우니 예외 메서드를 사용하는 편이 낫다.

특히 검사 예외는 복구할 것을 요구하므로, 클라이언트가 예외 상황에서 벗어나는데 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다. 예를 들어 카드 잔고가 부족해 검사 예외가 발생했다고 가정하자.(이 상황을 복구 가능하다고 판단했나보다) 그렇다면 이 예외는 잔고가 얼마나 부족한지를 알려주는 메소드를 제공해야한다.