[이펙티브 자바] 10장 : 예외

예외를 제대로 활용한다면 프로그램의 가독성, 신뢰성, 유지보수성을 높아지게 할수 있다.

아이템 69 : 예외는 진짜 예외 상황에서만 사용하라

아래 코드는 예외를 완전히 잘못 사용한 예이다.

try {
	int i = 0;
	while(true)
		range[i++].climb();
} catch (ArrayIndexOutOfBoundsException e) {
}

해당 코드는 무한루프를 돌다가 예외를 통해 끝을 내고 있다. 이 코드는 아마 배열 경계검사를 하지 않기에 성능이 더 좋을 거라 생각하고 쓴것 같다.

 

하지만 이는 잘못된 추론이다.

1. 예외는 예외 상황에서 쓸 용도로 설계되었고 최적화에 약하다.
2. try-catch 블록안에서는 JVM이 적용할 수 있는 최적화가 제한된다.
3. 배열을 순회하는 표준관용구는 중복 검사를 수행하지 않고 알아서 최적화한다.

예외를 일반적인 제어 흐름에서 사용하면 절대 안된다. 예외는 오직 예외 상황에서만 써야한다.

→ 예외를 일반적인 상황에서 사용하면 혼란을 야기할 수 있고 예외를 일반적인 상황으로 간주할 수 도 있다.

 

잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야한다.

→ 특정 상태에서만 호출할 수 있는 ‘상태 의존적' 메서드는 ‘상태 검사' 메서드도 함께 제공해야한다. 예) Iterator인터페이스의 ‘next’와 ‘hasNext’가 여기에 해당된다.

 

• ‘상태 의존적 메서드’를 제공하는 클래스는 ‘상태 검사 메서드’도 함께 제공해야 한다 (세트)

hasNext와 같은 ‘상태검사' 메서드를 제공하지 않는다면 ‘상태 의존적'인 메서드는 결국 예외를 발생시킬 수 밖에 없다. 이는 정상적인 흐름에서도 예외를 발생시키므로 좋지않은 방법이다.

다른 선택지로는 null이나 빈 옵셔널같은 특수한 값을 반환하는 방법이 있다.

 

상태 검사 메서드, 옵셔널, 특정 값 선택 가이드

1. 외부 동기화 없이 여러 스레드가 동시 접근하거나 외부 요인으로 상태가 변할 수 있다면
   • 옵셔널이나 특정 값
   • 상태 검사 메서드 호출 뒤 상태 의존 메서드 호출 한 사이 상태가 변할 수 있기 때문
2. 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 중복 수행한다면
   • 옵셔널이나 특정 값
3. 다른 모든 경우
   • 상태 검사 메서드 방식이 낫다
     • 가독성이 좋고, 잘못 사용했을 때 발견하기 쉽다.

-핵심정리- : 예외는 정상제어흐름이 아닌 예외상황에서만 사용하자.

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

자바는 문제상황을 알리는 타입으로 ‘검사예외, 런타임예외, 에러' 3가지를 제공한다.

이 3가지를 언제 무엇을 사용해야하는지 좋은 지침들을 살펴보자.

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

• 검사와 비검사를 구분하는 기본 규칙 (복구 가능 여부)
• 검사예외를 던지면 그 호출자나 API 사용자가 그 상황을 회복해내라고 요구한 것이다.

비검사 throwable은 크게 ‘런타임 예외'와 ‘에러'이다. 이 둘은 프로그램에서 잡을 필요가 없거나 잡지 말아야한다. 이 둘은 더 실행해봐야 실이 많기 때문에 스레드는 적절한 오류 메시지를 뱉으며 중단된다.

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

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

• 전제조건 위배란 클라이언트가 해당 API의 제약을 지키지 못했다는 뜻이다 [예) 인덱스는 음수가 될 수 없다]
• 프로그래밍 오류인지 애매하다면 복구 가능 여부로 검사예외인지, 런타임 예외인지를 판단하자.

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

• 자바 언어 명세가 요구하는 것은 아니지만 Error클래스를 상속해 하위클래스를 만드는 일은 자제하자.

우리가 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.

• Error는 상속이나 throw문으로 던지는일 이 없어야 한다.

Exception, RuntimeExcetion, throwable을 상속하지 않는 throwable을 만들 수 있지만 절대 사용하지 말자.

• 이는 정상적인 검사 예외보다 나을 게 없으면서 API사용자를 헷갈리게 만든다. (표준이 아니므로)

검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 함께 제공하자.

• 복구 가능한 예외이므로 복구 시 사용할 메서드도 함께 알려주자

 

아이템 71 : 필요 없는 검사 예외 사용은 피하라

검사 예외는 과하면 쓰기 불편한 API가 되고 적당히 요리하면 API의 질을 높일 수 있다.

• 검사예외가 과하면 API사용자에게 부담을 주게된다.
• 검사예외를 던지는 메서드는 자바 8에서 추가된 스트림 안에서 사용할 수 없다.

검사 예외를 회피하는 방법

• 결과 타입을 담은 옵셔널 반환. 검사 예외 대신 빈 옵셔널 반환
• 검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 변경 (hasNext(), next() 관계)

-핵심정리-

API호출자가 예외 상황에서 복구할 방법이 없다면 비검사예외를 던지자.

만약, 복구가 가능하고 처리를 해주길 원한다면 우선적으로 옵셔널을 반환해도 될지 고민하자. 옵셔널로 충분한 정보를 제공할 수 없을 때 ‘검사 예외'를 던지자.

아이템 72 : 표준 예외를 사용하라

숙련된 프로그래머는 그렇지 못한 프로그래머보다 더 많은 코드를 재사용한다..!

자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공한다.

 

표준 예외를 재사용하면

• API가 다른 사람이 익히고 사용하기 쉬워진다. 많은 다른 프로그래머들에게 익숙해진 규약을 따르기 때문이다.
• 예외 클래스가 적을수록 메모리 사용량, 클래스 적재 시간이 줄어든다.

---

IlegalArgumentException : 인수로 부적절한 값을 넘겼을 때

IllegalStateException : 대상 객체의 상태가 메서드 수행할 수 없을 때 (정상 초기화되지 않은 객체의 사용)

NullPointerException : null을 허용하지 않는 메서드에 null을 건낼 때

IndexOutOfBoundsException : 시퀀스의 허용범위를 넘는 값을 건낼 때

ConcurrentModificationException : 단일 스레드에서 사용하려 설계한 객체를 여러 스레드가 동시 수정하려 할 때

상황이 부합한다면 항상 표준 예외를 재사용하자. 이때 API문서를 참고해 그 예외가 어떤 상황에서 넘겨지는 지 확인해야만 한다.

만약, 더많은 정보를 제공하길 원한다면 표준예외를 확장하는 것도 좋다.

---

Exception, RuntimeException, Throwable, Error 는 직접 재사용하지 말자

마치 추상클래스라고 생각하고 직접 사용하지 말자.

• 여러 성격의 예외를 포괄하는 클래스이므로 안정적으로 테스트할 수 없다.

IllegalStateException과 IllegalArgumentException의 구분

인수값이 뭐였든 실패했을 상황이라면 전자를 선택, 그렇지 않다면 후자를 선택한다.

아이템 73 : 추상화 수준에 맞는 예외를 던지라

수행하려는 일과 관련 없는 예외가 나오면 당황스럽다. 이는 저수준예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 일어난다. (이는 내부 구현 방식을 드러내어 윗 레벨 API를 오염시킨다)

또한, 다음 릴리즈에서 구현 방식을 바꾸면 다른 예외가 튀어나와 기존 클라이언트 프로그램을 깨지게 할 수도 있다.

이 문제를 피하기 위해서는

상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야한다.

• 예외 번역

try {
	... // 저수준 추상화 사용
} catch (LowLevelException e) {
	// 추상화 수준에 맞게 번역
	throw new HighLevelEception(...);
}

 

• 예외 연쇄
  • 저수준 예외가 디버깅에 도움이 된다면 고수준 예외에 실어보낸다.

try {
	... // 저수준 추상화 사용
} catch (LowLevelException cause) {
	// 추상화 수준에 맞게 번역
	throw new HighLevelEception(cause);
}

 

예외를 처리할 때 필요하다면 저수준예외도 참고할 수 있다.

무턱대고 저수준 예외를 전파하는 것보다는 예외 번역이 우수한 방법이지만 남용하진 말자.

먼저 저수준 예외가 발생하지 않도록 노력하자.

• 상위 메서드에서 매개변수 값을 검사하자
• 그래도 예외가 발생한다면 상위 계층에서 예외를 조용히 처리하여 호출자에게 전달하지 않는 방법이 있다. 그리고 예외를 로깅해두어 나중에 필요한 조치를 취할 수 있다.

아이템 74 : 메서드가 던지는 모든 예외를 문서화하라

검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 ‘@throw’ 태그를 사용하여 정확히 문서화 하자.

메서드가 던질 수 있는 에외를 각각 @throws 태그로 문서화하되, 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자

• 검사인지 비검사인지에 따라 해야할 일이 달라지므로 메서드 사용자가 비검사 예외를 구분하게 하자.

한 클래스에 정의된 여러 메서드가 같은 이유로 같은 예외를 던진다면 그 예외를 (각각의 메서드가 아닌) 클래스 설명에 추가하는 방법도 있다.

아이템 75 : 예외의 상세 메시지에 실패 관련 정보를 담으라

실패 순간을 포착하려면 발생한 예외와 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 한다.

예시로 IndexOutOfBoundException 생성자는 String을 받지만 아래와 같이 실패 상황을 온전히 포착해도 좋았을 것이다.

public class IndexOutOfBoundsException extends RuntimeException {
    private final int lowerBound;
    private final int upperBound;
    private final int index;

    /**
     * IndexOutOfBoundsException을 생성한다.
     *
     * @param lowerBound 인덱스의 최솟값
     * @param upperBound 인덱스의 최댓값 + 1
     * @param index      인덱스의 실젯값
     */
    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;
    }
}

이렇게 해두면 프로그래머가 던지는 예외는 자연스럽게 실패를 더 잘 포착한다. 고품질의 상세 메시지를 예외 클래스 안으로 모아주므로 클래스 사용자가 메시지를 만드는 작업을 반복하지 않아도 된다.

또한, 예외는 실패와 관련된 정보를 얻을 수 있는 접근자 메서드를 적절히 제공하는 것이 좋다.

아이템 76 : 가능한 한 실패 원자적으로 만들라

호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야한다.

→ 이러한 특성을 ‘실패 원자적'이라고 한다.

• 메서드를 실패 원자적으로 만드는 방법
  • 불변 객체로 설계 (생성 시점에 고정되어 상태가 변하지 않음)
  • 가변 객체는 작업 수행 전 매개변수의 유효성 검사를 하는 것 (객체 내부 상태 변경 전 잠재적 예외를 걸러냄)
  • 실패할 가능성이 있는 모든 코드를 객체의 상태를 바꾸는 코드보다 앞에 배치한다
  • 객체의 임시 복사본에서 작업을 수행한 다음, 성공적으로 완료되면 원래 객체와 교체한다.
  • 작업 도중 발생하는 실패를 가로채는 복구 코드를 작성하여 작업 전 상태로 되돌린다

메서드 명세에 기술한 예외라면 예외가 발생하더라도 객체의 상태는 메서드 호출 전과 똑같이 유지돼야 한다. 이 규칙을 지키지 못하면 실패 시의 객체 상태를 API 설명에 명시해야만 한다. 이것은 많은 API문서에서 지켜지지 않고 있다.

아이템 77 : 예외를 무시하지 말라

API 설계자가 메서드 선언에 예외를 명시하는 까닭은 그 메서드를 사용할 때 적절한 조치를 취해달라고 요청하는 것이다...!

• 예외처리에서 아무것도 하지 않는 코드

try {
} catch (SomeException) {
}

catch 블록을 비워두면 예외가 존재할 이유가 없어진다

예외를 무시하기로 했다면 catch 블록 안에 그렇게 결정한 이유를 주석으로 남기고, 예외 변수의 이름도 ignored로 바꾸자

int numColors = 4;
try {
	numColors = f.get(1L, TimeUnit.SECONDS);
} catch (TimeOutException | ExecutionException ignored) {
  	// 기본값을 사용한다 (색상 수를 최소화하면 좋지만, 필수는 아니다).
}

예외를 못 본척하고 지나치면 프로그램은 오류를 내재한 채 동작하게 된다.

이는 어느 순간 문제의 원인과 아무 상관없는 곳에서 갑자기 죽어버릴 수 있다.

오류를 적절히 처리하거나 무시하지 않고 바깥으로 전파라도 하자. 이렇게라도 해야 디버깅정보는 남겨두고 프로그램이 죽게할 수 있다.