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

검사 예외와 런타임 예외

• 자바는 문제 상황을 알리는 타입(Throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 세 가지를 제공한다.
• 하지만, 해당 타입을 언제 무엇을 사용해야하는 지 헷갈리는 경우가 있다.

참고 지침

• 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.
  • 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다.
  • 따라서, 메소드 선언에 포함된 검사 예외 각각은 그 메소드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.
  • 비검사 throwable은 두 가지로, 런타임 예외와 에러이다.
  • 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다.
  • 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득이 없다는 뜻이다.
  • 검사 예외 는 일반적으로 복구할 수 있는 조건일 때 발생한다. 따라서 호출자가 예외 상황에서 벗어나는데 필요한 정보를 알려주는 메소드를 함께 제공하는 것이 중요하다.
• 프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자
  • 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.
  • 여기서 전제조건을 만족하지 못했다라는 것은, 단순히 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다라는 뜻이다.
  • 하지만 실제로 해당 상황이 복구가 가능한 상황인지 아닌지는 판단하기 어렵다. 사실상 API 설계자의 판단에 달렸다.
  • 그러므로, 복구가 가능하다고 판단되면 검사예외를, 그렇지 않다면 런타임 예외, 확신이 어렵다면 비검사 예외를 선택해라.
• 에러는 보통 JVM이 자원부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황일 때 사용한다
  • 자바 언어의 널리 퍼진 규약으로 Error 클래스를 상속해 하위 클래스를 만드는 일을 자제하는 것이 좋다. 다시 말해서, 우리가 구현하는 비검사 throwble은 모두 RuntimeException의 하위 클래스여야 한다.
  • Error는 상속하지 말아야할 뿐 아니라, throw 문을 직접 던지는 일도 없어야한다.(AssertionError는 예외)
  • Exception, RuntimeException, Error를 상속하지 않은 throwble을 만들 수 있는데 이런, throwable은 이로울 게 없으니 절대 사용하지 말아라. 이런 throwable은 예외보다 나을 게 없으며 API 사용자를 헷갈리게 할 뿐이다.
  • 예외의 메소드는 주로 그 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는데 쓰인다. 그러나 throwable 클래스들은 대부분 오류 메시지 포맷을 상세히 기술하지 않는다. 이것은, JVM이나 릴리스에 따라 포맷이 달라질 수 있다는 뜻이다.

핵심 정리

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