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

Throwable

• 문제 상황을 알리는 타입

• 종류는 아래와 같이 3가지이다.

  • 검사 예외 (checked Exception)

  • 비검사 예외 (unchecked Exception)

    • 런타임 예외

    • 에러

검사 예외

• 호출하는 쪽에서 복구 가능하다고 여겨지는 상황일 때 사용

• 호출자가 예외를 try-catch로 처리하거나 더 바깥으로 전파하도록 강제하는 예외이다.

• 쉽게 말하면, 예외 처리하지 않으면 컴파일이 불가능하므로 반드시 체크해줘야하는 예외이다.

• try-catch로 발생 장소에서 예외 처리해주는 것이 좋다.

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

void method() throws Exception1, Exception2, ... ExceptionN {
    //메서드의 내용
}

비검사 예외

• 복구가 불가능하거나, 복구할 수 있을지 확실하지 않거나, 더 실행할 필요가 없을 때 사용한다.

• throwable을 잡지 않은 스레드는 적절한 오류메시지를 던지며 중단된다.

• 프로그램 실행 중 발생하기 때문에 예측하기 어려워 예외 처리를 강제하지 않는다.

런타임 예외

• 프로그래밍 오류를 나타낼 때 사용

• 런타임 예외의 대부분은 전제조건(API 명세에 기록된 제약)을 만족하지 못했을 때 발생한다.

  • ex) 배열의 인덱스가 0 ~ {배열길이-1} 사이의 값이 아니라면 ArrayIndexOutOfBoundsException 발생

🛑 자원 고갈 문제

• 말도 안되는 크기의 배열을 할당해 생긴 프로그래밍 오류일 수도 있고 진짜로 자원이 부족해서 발생할 수도 있다.

• 자원이 일시적으로 부족하거나 수요가 순간적으로 몰린 경우라면 복구할 수 있을 것이다.

• API 설계자의 판단에 따른 복구 여부를 통해 어떤 예외를 던질 지 결정해야 한다.

에러

• JVM이 자원 부족, 불변식 깨짐 등으로 인해 더 이상 수행할 수 없는 상황을 나타낼 때 사용

• 직접 구현하는 비검사 예외(throwable)는 모두 RuntimeException의 하위 클래스여야 한다.

• Error는 상속하지도 말고, throw문도 던지지 말자! (AssertionError는 예외)

예외의 메서드

• 예외의 메서드는 주로 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달할 때 쓰인다.

• 메서드를 제공하지 않으면 클라이언트가 직접 오류 메세지를 파싱해 정보를 빼내야 하므로 나쁜 코드가 된다.

• 검사 예외라면 예외 상황을 벗어나는 데 필요한 정보를 알려주는 메서드를 제공해 클라이언트가 복구할 수 있도록 하는 것이 중요하다.