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

검사 예외와 런타임 예외

자바는 문제 상황을 알리는 타입(Throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 세 가지를 제공한다.

하지만, 해당 타입을 언제 무엇을 사용해야하는 지 헷갈리는 경우가 있다.

 

 

그럼 이것들은 언제 무엇을 사용해야 하는가?

• 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용해라

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

따라서, 메소드 선언에 포함된 검사 예외 각각은 그 메소드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.

Ex. API 메소드 호출 시 강제적으로 try-catch 혹은 throw 를 해야하는 경우

 

비검사 throwable은 두 가지로, 런타임 예외와 에러이다.

이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다. why? 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득이 없다는 뜻이다.

 

검사 예외 는 일반적으로 복구할 수 있는 조건일 때 발생한다. 따라서 호출자가 예외 상황에서 벗어나는데 필요한 정보를 알려주는 메소드를 함께 제공하는 것이 중요하다.

 

 

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

런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.

여기서 전제조건을 만족하지 못했다라는 것은, 단순히 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다라는 뜻이다.

Ex. 배열의 인덱스는 0 ~ n-1 사이어야 한다. But, ArrayIndexOutOfBoundsException이 발생했다는 것은 전제조건이 지켜지지 않았다는 뜻이다.

 

하지만 실제로 해당 상황이 복구가 가능한 상황인지 아닌지는 판단하기 어렵다. 사실상 API 설계자의 판단에 달렸다.

그러므로, 복구가 가능하다고 판단되면 검사예외를, 그렇지 않다면 런타임 예외, 확신이 어렵다면 비검사 예외를 선택해라.

 

 

• 에러는 보통 JVM이 자원부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황일 때 사용한다.

자바 언어의 널리 퍼진 규약으로 Error 클래스를 상속해 하위 클래스를 만드는 일을 자제하는 것이 좋다. 다시 말해서, 우리가 구현하는 비검사 throwble은 모두 RuntimeException의 하위 클래스여야 한다.

 

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

Exception, RuntimeException, Error를 상속하지 않은 throwble을 만들 수 있는데 이런, throwable은 이로울 게 없으니 절대 사용하지 말아라. 이런 throwable은 예외보다 나을 게 없으며 API 사용자를 헷갈리게 할 뿐이다.

 

예외의 메소드는 주로 그 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는데 쓰인다. 그러나 throwable 클래스들은 대부분 오류 메시지 포맷을 상세히 기술하지 않는다. 이것은, JVM이나 릴리스에 따라 포맷이 달라질 수 있다는 뜻이다.

 

 

핵심 정리

복구할 수 있는 상황이면 검사 예외

프로그래밍 오류라면 런타임 예외

확실하지 않다면 비검사 예외

검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지 말아라.

검사 예외라면 복구에 필요한 정보를 알려주는 메소드도 제공하자.