Portfolio

💡

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

지침

호출하는 쪽에서 복구 하리라(해당 로직을 성공시킬 수 있도록) 여겨지는 상황이라면 검사 예외를 사용하라 (이것이 검사와 비검사 예외를 구분하는 기본 규칙임)

검사 예외 던지면 호출자가 catch로 처리하거나, 더 바깥으로 전파하도록 강제하게 됨

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

즉, API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한 것

비검사 throwable은 두 가지 (RuntimeException, Error)

이들은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로는 잡지 말아야 함(즉, 해당 로직을 성공시킬 수 있는 방법이 없다는 것)

예) DataIntegrityViolationException이 던져 졌으면 insert 불가한 거니까 복구가 불가능한 것. 실패 시켜야 함

프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻임 → 적절한 오류 메시지를 내 뱉으며 중단됨

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

런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생함

즉, 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 뜻

위의 조건에서 문제가 있다면, 복구할 수 있는 상황인지 프로그래밍 오류인지가 항상 명확히 구분되지는 않는다는 점

복구 가능하다고 믿는다면 검사 예외를, 그렇지 않다면 런타임 예외. 확신하기 어려우면 비검사 예외 선택(아이템 71: 필요없는 검사 예외 사용은 피해라)

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

예외 역시 어떤 메서드라도 정의할 수 있는 완벽한 객체임. 예외의 메서드는 주로 그 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는 데 쓰임. 이런 메서드가 없다면 프로그래머들은 오류 메시지를 파싱해 정보를 빼내야 하는데, 대단히 나쁜 습관이다(JVM이나 릴리스에 따라 포맷이 달라질 수 있기에)


public IndexOutOfBoundsException(int lowerBound, int upperBound, int index) {
	super(String.format("최솟값: %d, 최댓값: %d, 인덱스: %d",
				lowerBound, upperBound, index));

	this.lowerBound = lowerBound;
	this.upperBound = upperBound;
	this.index = index;
}

예외 생성자 예시. 이런식으로 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달. 예외 오류 메시지를 파싱해서 거기서 정보를 빼내는 것이 아니라

검사 예외는 일반적으로 복구할 수 있는 조건일 때 발생하기에 호출자가 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요함

예로, 쇼핑몰에서 물건을 구입하려는데 카드 잔고가 부족하여 검사 예외 발생 → 잔고가 얼마나 부족한지 알려주는 접근자 메서드를 제공해야 함

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

지침