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

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

---

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

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

위 3가지의 사용 시점을 헷갈리는 개발자가 많으니 그에 관련한 지침을 알아보자

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

• 검사와 비검사 예외를 구분하는 기본 규칙이다
  • 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다
  • 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다
• 비검사 throwable은 런타임 예외와 에러 두가지다
  • 둘다 동작 측면에서는 다르지 않으며 이 둘은 프로그램에서 잡을 필요가 없거나 잡지 않아야 한다
  • 비검사 예외를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다 실이 많다는 것이다
  • 이런 throwable을 잡지 않은 스레드는 적절한 오류 메세지를 뱉고 중단된다

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

• 런타임 예외의 대부분은 전제조건을 만족하지 못하는 경우 발생한다
  • 전제조건 위배 : 클라이언트가 API 명세에 기록된 제약을 지키지 못했다는것
  • 전제조건 위배 조건에서 문제는 복구할 수 있는 상황인지 프로그래밍 오류인지가 항상 명확히 구분되지 않는다는 것
    • ex) 자원 고갈은 말도 안되는 크기의 배열을 할당해서 생기는 오류일수도 있지만 진짜 자원이 부족해서 발생한 문제일수도 있다
  • 복구가 가능한 상황이라면 검사예외를 사용하고 아니면 런타임 예외를 사용 확신하기 어렵다면 비검사 예외를 선택하는게 나을것이다

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

• "Error 클래스를 상속해서 하위 클래스를 만드는 걸 자제하라" 이 말은 자바 명세가 요구하는건 아니지만 업계에 퍼진 규약이니 지키도록 하자
  • 우리가 구현하는 비검사 throwable 은 모두 RuntimeException 의 하위 클래스여야 한다
  • 직접적이든 간접적이든 Error는 상속하지 말아야 하며 throw 문으로 직접 던지는 일도 없어야 한다(AssertionError는 예외)

검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지도 말고 검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자