Effective Java 3rd - Ch10 | 태주네 블로그

Java 기초를 다지기 위해 효과적인 자바란 책을 공부 중입니다.

제10장 예외

잘 활용하면 프로그램의 가독성, 신뢰성, 유지보수성이 높아진다
예외를 효과적으로 활용하는 지침에 대해 설명


<그림> Java-Exception-Class

참고1 : Java 예외(Exception) 처리에 대한 작은 생각

구분	checked exception	unchecked exception
처리여부	반드시 예외를 처리해야 함	명시적인 처리를 강제하지 않음
확인시점	컴파일 단계	실행 단계
예외발생시 트랜잭션 처리	roll-back 하지 않음	roll-back 함
대표적인 예외	Exception 의 상속받는 하위 클래스 중 Runtime Exception 을 제외한 모든 예외 - IOException - SQLException	RuntimeException 의 하위 예외 - NullPointerException - IllegalArgumentException - IndexOutOfBoundsException - SystemException

예외 처리 방법

예외 복구 : 다른 작업 흐름으로 유도
예외처리 회피 : 처리하지 않고 호출한 쪽으로 throw
예외 전환 : 명확한 의미의 예외로 전환 후 throw

참고2 : 자바의 예외처리

Error 는 JVM 에서 생성되거나, 나타나는 예외입니다.

기본적으로 unchecked exception : 해당 에러를 처리
JVM 을 위한 것으로 애플리케이션의 범위를 벗어나기 때문에 애플리케이션 단에서는 처리하지 않는다

Exception 은 ‘예상할 수 있는 예외’ 로 ‘프로그래머가 만드는 예외’ 이기도 함

Checked Exception : 확인이 요구되는 예외
- 예) FileNotFoundException
Unchecked Exception : 예외는 발생할 수 있지만 강제되지 않는 예외
- 계속 상위 Caller 에게로 Throws 하다보면 JVM 이 받아서 처리 (종료)
- 예) NullPointerException

69) 예외는 진짜 `예외 상황`에서만 사용하라

코드 69-1 예외를 완전히 잘못 사용한 예 - 따라하지 말것!

  


try{
    int i =0;
    while(true)                 // 무한루프
        range[i++].climb();     // 결국 예외 발생

    // 올바른 관용구
    // for( Mountain m : range ) m.climb();

} catch( ArrayIndexOutOfBoundsException e) {
    ...   // 루프 종료에 대한 반복 검사를 피하려고 꼼수 사용
}

예외에 대한 잘못된 생각

예외는 예외 상황에 쓸 용도로 설계되었기 때문에 빠르게 만들지 않았다
- 길이 100 정도의 배열로 테스트시 2배 정도 느리다
코드를 try-catch 블록 안에 넣으면 JVM 의 최적화가 제한된다
올바른 순회 관용구는 앞서 걱정한 반복 검사를 수행하지 않는다 (알아서 최적화)

예외에 대한 올바른 생각

예외는 오직 예외 상황에서만 써야 한다
- 절대로 일상적인 제어 흐름용으로 쓰여선 안된다
잘 설계된 API 라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다
- 특정 상태에서만 호출할 수 있는 ‘상태 의존적’메서드를 제공하는 클래스는 ‘상태 검사’메서드도 함께 제공해야 한다
  - ex) Iterator 인터페이스의 next(상태 의존적 메서드) 와 hasNext(상태 검사 메서드)

  


for( Iterator<Foo> i = collection.iterator(); i.hasNext(); ){
    Foo foo = i.next();
    ...
}

///////////////////////////////

// 만약 hasNext 함수가 없다면 이런 식으로 작성했을 것이다
// 컬렉션을 이런 식으로 순회하지 말 것!
try{
    Iterator<Foo> i = collection.iterator();
    while(true) {
        Foo foo = i.next();
        ...
    }
} catch( NoSuchElementException e ){ ... }

상태 검사 메서드 대신 사용할 수 있는 다른 옵션들에 대한 지침

올바르지 않은 상태일 때 빈 옵셔널 혹은 null 같은 특수한 값을 반환
외부 요인으로 상태가 변할 수 있다면 옵셔널이나 특정값을 사용한다
- 상태 검사 메서드와 상태 의존적 메서드 호출 사이에 객체의 상태가 변할 수 있기 때문
성능이 중요한 상황에서 반복 검사를 한다면 옵셔널이나 특정값을 선택한다
그 외의 경우엔 상태 검사 메서드 방식이 조금 더 낫다
- 가독성이 좋고, 문제 발생시 상태 의존적 메서드가 예외를 던져 버그를 확실히 보여줄 것이다
- 반면 특정값은 검사하지 않고 지나쳐도 발견하기가 어렵다 (옵셔널은 제외)

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

자바는 검사 예외, 런타임 예외, 에러, 이렇게 세가지 throwable 타입을 제공한다

호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라
- 발생할 수 있는 유력한 상황으로, API 설계자는 그 상황에서 회복해내라고 요구한 것이다
  - 사용측에서 아무 조치도 않하는 것은 좋지 않은 생각이다 (ex: FileNotFound)
- 검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자
프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자 (비검사 예외)
- 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다
  - 전제 조건을 만족시키지 않는 상황이 복구 가능하다면 검사 예외를, 확신하기 어렵다면 비검사 예외를 선택하라
에러는 보통 JVM 자원부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다
- 여러분이 구현하는 비검사 throwable 은 모두 RuntimeException 의 하위 클래스여야 한다
- 에러는 상속하지 말아야 할 뿐 아니라, throw 문으로 직접 던지는 일도 없어야 한다
  - AssertionError 는 예외
확실하지 않다면 비검사 예외를 던지자 : 런타임 예외와 에러
- 프로그램에서 비검사 예외를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다
  - 프로그램이 중단된다
검사 예외도 아니고 런타임 예외도 아닌 throwable 은 정의하지도 말자

71) `필요 없는` 검사 예외 사용은 피하라

검사 예외는 발생한 문제를 프로그래머가 처리하여 안전성을 높이게끔 해준다.
다만, 피할 수 있으면 피하는 것이 좋다.

catch 블록 처리 또는 바깥으로 던지든 API 사용자에게 부담을 준다
예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없다

  


// 다음과 같이 하는게 최선인가?

try {
    ...
} catch (TheCheckedException e) {
    throw new AssertionError();     // 일어날 수 없다
}

// 아니면 다음 방식은 어떤가?

try {
    ...
} catch (TheCheckedException e) {
    e.printStackTrace();            // 이런, 우리가 졌다
    System.exit(1);
}

// 더 나은 방법이 없다면 비검사 예외를 선택해야 한다

검사 예외를 회피하는 방법

적절한 결과 타입을 담은 옵셔널을 반환하는 것 (가장 쉬운 방법!!)
- 검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환하면 된다
- 단점 : 예외가 발생한 이유를 알려주는 부가 정보를 담을 수 없다
검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 바꿀 수 있다
- 상태 검사 메서드를 사용
  - 중복 사용에서 성능적인 손해가 발생할 수 있다

코드 71-1 검사 예외를 던지는 메서드 - 리팩토링 전

  


try {
    obj.action(args);
} catch (TheCheckedException e) {
    ... // 예외 상황에 대처한다
}

코드 71-2 상태 검사 메서드와 비검사 예외를 던지는 메서드 - 리팩토링 후

  


// 예외가 던져질지 여부를 boolean 값으로 반환한다
// 상태 검사 메서드 : actionPermitted
if( obj.actionPermitted(args) ) {
    obj.action(args);
} else {
    ... // 예외 상황에 대처한다
}

이 리팩토링을 모든 상황에 적용할 수 없겠지만, 적용할 수만 있다면 더 쓰기 편한 API 를 제공할 수 있다.

72) `표준 예외`를 사용하라

표준 예외를 재사용하면 얻는게 많다.

여러분의 API 가 다른 사람이 익히고 사용하기 쉬워진다
예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다

많이 사용되는 예외들

예외	주요 쓰임
IllegalArgumentException	허용하지 않는 값이 인수로 건네졌을 때 (null 은 따로 NullPointerException 으로 처리)
IllegalStateException	객체가 메서드를 수행하기에 적절하지 않은 상태일 때
NullPointerException	null 을 허용하지 않는 메서드에 null 을 건넸을 때
IndexOutOfBoundsException	인덱스가 범위를 넘어섰을 때
ConcurrentModificationException	허용하지 않는 동시 수정이 발견됐을 때
UnsupportedOperationException	호출한 메서드를 지원하지 않을 때
ArithmeticException NumberFormatException	복소수나 유리수를 다루는 객체 사용시 취급

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

73) `추상화 수준`에 맞는 예외를 던져라

수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 것이다.

메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 일어남
내부 구현 방식을 드러내어 윗 레벨 API 를 오엄시킨다

이 문제를 피하려면 예외 번역을 해야 한다.
상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준의 예외로 바꿔 던져야 한다.

코드 73-1 예외 번역

  


try {
    ... // 저수준 추상화를 이용한다
} catch( LowerLevelException e ){
    // 추상화 수준에 맞게 번역한다
    throw new HigherLevelException(...);
}

다음은 AbstractSequentialList 에서 수행하는 예외 번역의 예

  


/**
 * 이 리스트 안의 지정한 위치의 원소를 반환한다.
 * @throws IndexOutOfBoundsException index 가 범위 밖이라면,
 *         즉 ({@code index < 0 || index >= size()}) 이면 발생한다.
 */
public E get(int index) {
    ListIterator<E> i = listIterator(index);
    try{
        return i.next();
    } catch( NoSuchElementException e ){    // 예외 번역
        throw new IndexOutOfBoundsException("인덱스: "+index);
    }
}

예외를 번역할 때, 저수준 예외가 도움이 된다면 예외 연쇄를 사용하는게 좋다.

예외 연쇄 : 문제의 근본 원인인 저수준 예외를 고수준 예외에 실어 보내는 방식
필요시 별도의 접근자 메서드(Throwable 의 getCause 메서드)를 통해 언제든 저수준 예외를 꺼내볼 수 있다

코드 73-2 예외 연쇄

  


try {
    ... // 저수준 추상화를 이용한다
} catch( LowerLevelException cause ){
    // 저수준 예외를 고수준 예외에 실어 보낸다
    throw new HigherLevelException( cause );
}

코드 73-3 예외 연쇄용 생성자

  


class HigherLevelException extends Exception {
    HigherLevelException( Throwable cause ){
        super(cause);
    }
}

대부분의 표준 예외는 예외 연쇄용 생성자를 갖추고 있다.
Throwable 의 initCause 메서드를 이용해 ‘원인’을 직접 못박을 수 있다.

가능하다면 저수준 메서드가 반드시 성공하도록 하여 아래 계층에서는 예외가 발생하지 않도록 하는 것이 최선이다.
차선책: 상위 계층에서 예외를 조용히 처리하여 문제를 API 호출자에까지 전파하지 않는 방법
이 경우 적절한 로깅 기능을 활용하여 기록해두면 좋다.

74) 메서드가 던지는 모든 예외를 `문서화`하라

메서드가 던질 가능성이 있는 모든 예외를 문서화 하라!

검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자.
메서드가 던질 수 있는 예외를 각각 @throws 태그로 문서화하되, 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자.
한 클래스에 정의된 많은 메서드가 같은 이류로 같은 예외를 던진다면 그 예외를 (각각의 메서드가 아닌) 클래스 설명에 추가하는 방법도 있다.

문서화 예

  


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

    /**
     * Constructs an IndexOutOfBoundsException.
     *
     * @param lowerBound the lowest legal index value
     * @param upperBound the highest legal index value plus one
     * @param index      the actual index value
     */
    public IndexOutOfBoundsException(int lowerBound, int upperBound,
                                     int index) {
        // Generate a detail message that captures the failure
        super(String.format(
                "Lower bound: %d, Upper bound: %d, Index: %d",
                lowerBound, upperBound, index));

        // Save failure information for programmatic access
        this.lowerBound = lowerBound;
        this.upperBound = upperBound;
        this.index = index;
    }
}

75) 예외의 `상세 메시지`에 실패 관련 정보를 담아라

실패 원인을 분석해야 하는 프로그래머가 얻을 수 있는 유일한 정보이기 때문에
예외의 toString 메서드에 실패 원인에 관한 정보를 가능한 한 많이 담는 일은 아주 중요하다.

실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 한다.
상세 메시지에 비밀번호나 암호키 같은 정보까지 달아서는 안된다.

예외의 상세 메시지와 최종 사용자에게 보여줄 오류 메시지를 혼동해서는 안된다.
최종 사용자에게는 친절한 안내 메시지를, 예외 메시지는 가독성보다 담긴 내용이 훨신 중요하다.

실패를 적절히 포착하려면 필요한 정보를 예외 생성자에서 모두 받아서 상세 메시지까지 미리 생성해 놓는 방법도 괜찮다.

  


/**
 * 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) 가능한 한 `실패 원자적`으로 만들어라

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

메서드를 실패 원자적으로 만드는 방법

불변 객체로 설계하는 것 (태생적으로 실패 원자적)
- 불변 객체의 상태는 생성 시점에 고정되어 절대 변하지 않기 때문
가변 객체의 메서드의 경우 작업 수행에 앞서 매개변수의 유효성을 검사하는 것
- 잠재적 예외의 가능성 대부분을 걸러낼 수 있다
- 실패할 가능성이 있는 모든 코드를, 객체의 상태를 바꾸는 코드보다 앞에 배치하는 방법
객체의 임시 복사본에서 작업을 수행한 다음, 작업이 성공하면 원래 객체와 교체하는 것
- 예: 정렬 알고리즘에서 정렬 전 원소들을 배열로 옮겨 담아 수행 (입력 리스트는 변하지 않음)
작업 도중 발생하는 실패를 가로채는 복구 코드를 작성 (작업 전 상태로 되돌린다)

  


public Object pop() {
    // size 가 음수가 되면 ArrayIndexOutOfBoundsException 발생
    // ==> 추상화 수준에 어울리지 않는다
    if( size == 0 ) throw new EmptyStackException();

    Object result = elements[--size];
    elements[size] = null;      // 다 쓴 참조 해제
    return result;
}

실패 원자성은 일반적으로 권장되지만 항상 달성할 수 있다고 짐작해서는 안된다.

예) 동시성 처리에서 예외를 잡았다고 객체를 여전히 쓸 수 있을지는 모른다
Error 는 복구할 수 없으므로 실패 원자적 조치를 시도조차 할 필요가 없다 (AssertionError)
실패 원자적으로 만들기 위한 비용이 크다면 하지 마라

77) 예외를 무시하지 말라

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

무시하지 않고 바깥으로 전파되게만 놔둬도 최소한 디버깅 정보를 남긴 채 프로그램이 신속히 중단되게는 할 수 있다.

  


// catch 블록을 비워두면 예외가 무시된다. 아주 의심스러운 코드다
// 비유하자면 화재경보를 화재경보를 아예 꺼버려 누구도 알지 못하게 하는 것과 같다
try {
    ...
} catch( SomeException e ) {
}

물론 예외를 무시해야 할 때도 있다.

예) FileInputStream 을 닫을 때, 파일의 상태를 변경하지 않았으니 예외 처리할 것도 없다.
예외를 무시하기로 했다면 catch 블록안에 이유를 주석으로 남기고, 예외 변수의 이름도 ignored 로 바꿔놓도록 하자.

  


Future<Integer> f = exec.submit(planarMap::chromaticNumber);
int numColors = 4;  // 기본값. 어떤 지도라도 이 값이면 충분하다
try {
    numColors = f.get(1L, TimeUnit.SECONDS);
} catch( TimeoutException | ExecutionException ignored ){
    // 기본값을 사용한다
}

끝! 읽어주셔서 감사합니다.

Effective Java 3rd - Ch10

제10장 예외

69) 예외는 진짜 예외 상황에서만 사용하라

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

71) 필요 없는 검사 예외 사용은 피하라

검사 예외를 회피하는 방법

72) 표준 예외를 사용하라

73) 추상화 수준에 맞는 예외를 던져라

74) 메서드가 던지는 모든 예외를 문서화하라

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

76) 가능한 한 실패 원자적으로 만들어라

77) 예외를 무시하지 말라

관련된 글

Effective Java 3rd - Contents

Effective Java 3rd - Ch02

Effective Java 3rd - Ch03