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

문제 상황을 알리는 타입

• 자바의 문제 상황을 알리는 타입(throwable) 세 가지

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

• 언제 무엇을 사용해야 하는지 헷갈리는 경우가 있다.

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

검사와 비검사 예외를 구분하는 기본 규칙이다.

• 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제학레 된다.
• 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.
• 즉 API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한 것

비검사 throwable

런타임 예외와 에러

• 프로그램에서 잡을 필요가 없거나 혹은 통장적으로는 잡지 말아야 한다.
• 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다.
• 이런 throwable을 잡지 않은 스레드는 적절한 오류 메시지를 내뱉으며 중단된다.

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

• 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생된다.
• 전제조건 위배란
  • 단순히 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 뜻이다.
  • 예컨대 배열의 인덱스는 0에서 '배열 크기 -1' 사이여야 한다. ArrayIndexOutOfBoundsException이 발생했다는 건 이 전제조건이 지켜지지 않았다는 뜻이다.
• 이상의 조건에서 문제가 하나 있다면, 복구될 수 있는 상황인지 프로그래밍 오류인지가 항상 명확히 구분되지는 않는다는 사실이다.
• 확신하기 어렵다면 아마도 비검사 예외를 선택하는 편이 낫다.

에러

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

• Error 클래스를 상속해 하위 클래스를 만드는 일은 자제하자
• 우리가 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.
• Error는 상속하지 말아야 할 뿐 아니라, throw 문으로 직접 던지는 일도 없어야 한다.
  • AssertionError는 예외다.

예외

• API 설계자들도 예외 역시 어떤 메서드라도 정의할 수 있는 완벽한 객체라는 사실을 잊곤 한다.
• 예외의 메서드는 주로 그 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는 데 쓰인다.
• 검사 예외는 일반적으로 복구할 수 있는 조건일 때 발생한다.
  • 따라서 호출자가 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공해주는 것이 중요하다.

---

💡 핵심 정리

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