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는 예외)
예외의 메서드
예외의 메서드는 주로 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달할 때 쓰인다.
메서드를 제공하지 않으면 클라이언트가 직접 오류 메세지를 파싱해 정보를 빼내야 하므로 나쁜 코드가 된다.
검사 예외라면 예외 상황을 벗어나는 데 필요한 정보를 알려주는 메서드를 제공해 클라이언트가 복구할 수 있도록 하는 것이 중요하다.
Last updated