Hyerin Blog
예외


69. 예외는 진짜 예외 상황에만 사용하자.

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

위 코드는 무슨 일을 하는 걸까?
전혀 직관적이지 않다. 배열의 원소를 순회하는데 무한루프를 돌다가 배열의 끝에 도달해
ArrayIndexOutOfBoundsException이 발생하면 끝을 내는 코드이다.

다음과 같이 변경하면 개발자는 바로 이해했을 것이다.

for(Mountain m : range) { // 표준 관용구 
    m.climb();
}

Q. 왜 예외를 써서 루프를 종료했을까?
A. 잘못된 추론을 근거로 성능을 높여보려 한 것이다.

JVM은 배열에 접근할 때마다 경계를 넘지 않는지 검사하는데 일반적인 반복문도 배열 경계에 도달하면 종료한다.
따라서 이 검사를 반복문에도 명시하면 같은 일이 중복되므로 하나를 생략한 것이다.
그러나 잘못된 추론이다.
실제로는 예외를 사용한 쪽이 표준 관용구보다 훨씬 느리다.


잘못된 추론

  1. 예외는 예외 상황에 쓸 용도로 설계되었으므로 JVM 구현자 입장에서는 명확한 검사만큼 빠르게 만들어야 할 동기가 약하다.
    (최적화에 별로 신경쓰지 않았을 가능성이 크다.)
  2. 코드를 try-catch 블록 안에 넣으면 JVM이 적용할 수 있는 최적화가 제한된다.
  3. 배열을 순회하는 표준 관용구는 앞서 걱정한 중복 검사를 수행하지 않는다.
    JVM이 알아서 최적화를 없애준다.


예외를 사용한 반복문의 문제점


예외 원칙


상태 검사 메서드 대신 사용 가능한 선택지

  1. 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인으로 상태가 변할 수 있다면 옵셔널이나 특정 값을 사용한다.
    • 상태 검사 메소드와 상태 의존적 메소드 호출 사이에 객체의 상태가 변할 수 있기 때문이다.
  2. 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메소드의 작업 일부를 중복 수행한다면 옵셔널이나 특정 값을 사용한다.
  3. 그 외 다른 경우에는 상태 검사 메소드를 사용하는 것이 낫다.



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

자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 세 가지를 제공한다.


오류(Error)


예외(Exception)


검사 예외(Checked Exception)


런타임 예외(Runtime Exception)


검사 예외


비검사 - 런타임 예외, 에러


에러


핵심 정리



71. 필요 없는 검사 예외 사용은 피하자.

검사 예외는 제대로 활용하면 api와 프로그램의 질을 높일 수 있다.
검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높이게끔 해준다.
물론 검사 예외를 사용하면, 오히려 쓰기 어려운 api가 된다.
어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드쪽에서 반드시 그 예외를 처리해 주어야 한다.
이를 붙잡아(catch) 처리하거나 혹은 더 바깥으로 던져 문제를 전파해야된다.

검사 예외 회피하기

검사 예외를 회피하는 가장 쉬운 방법은 적절한 결과 타입을 담은 옵셔널을 반환하는 것이다.
검사 예외를 던지는 대신에 단순히 빈 옵셔널을 반환하면 된다.
이 방식의 단점은 예외가 발생한 이유를 알려주기 어렵다는 것이다.

혹은 두개의 메서드로 쪼개는 방법이 있다.

검사 예외를 두개의 메서드로 쪼개기

// 리펙토링 전 메서드
try {
	obj.action(args);
} catch (TheCheckedExcpetion e) {
	// ...
}


// 리펙토링 후 메서드
if(obj.actionPermitted(args)) {
	obj.action(args);
} else {
	// ...
}

이렇게 예외 케이스인지 검사하는 메서드를 추가하고 예외 케이스인 경우에는
런타임 익셉션(Unchecked exception)으로 해결하는 방법도 있다.
이 방식을 모든 코드에 적용할 수는 없지만, 훨씬 유연한 구조임은 사실이다.



72. 표준 예외를 사용하자.

표준 예외를 재사용하면 장점이 많다.
내가 작성한 API가 다른 사람이 익히고 사용하기 쉬워진다는 것이다.
예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다.

IllegalArgumentException

가장 많이 사용되는 예외이다. 호출자가 인수로 부적절한 값을 넘길 때 던지는 예외이다.
사용 예시) 반복 횟수를 지정하는 매개변수에 음수를 건넬 때

IllegalStateException

대상 객체의 상태가 호출된 메서드를 수행하기에 적합하지 않을 때 주로 사용된다.
사용 예시) 제대로 초기화되지 않은 객체를 사용하려고 할 때

ConcurrentModificationException

단일 스레드에서 사용하려고 설계한 객체를 여러 스레드가 동시에 수정할 때 던진다.

UnsupportedOperationException

클라이언트가 요청한 동작을 대상 객체가 지원하지 않을 때 사용된다.
사용 예시) 원소를 넣을수만 있는 List의 구현체에 누군가 remove 메서드를 호출할 때

그 외

Exception, RuntimeException, Throwable, Error는 직접 사용하지 말자.
이 클래스들은 추상 클래스라고 생각하면 된다.
이 예외들은 다른 예외들의 상위 클래스이므로 안정적으로 테스트 하기 어렵다.



73. 추상화 수준에 맞는 예외를 던지자.

수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 것이다.
이는 윗 레벨 api를 오염 시킬 수 있다.

예외 번역(Exception translation)

앞서 서술한 문제를 피하기 위해서는 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꾸어 주어야 한다.
이를 예외 번역이라고 한다.


예시

try {
	// 저수준 추상화를 이용
} catch (LowerLevelException e) {
	throw new HigherLevelException();
}


AbstractSequentialList에서 수행하는 예시

public E get(int index) {
	ListIterator<E> i = listIterator(index);
	try {
		return i.next();
	} catch (NoSuchElementException e) {
		throw new IndexOutOfBoundsException("인덱스: " + index);
	}

}


예외를 번역하기

저수준 예외가 디버깅에 도움이 될 때가 있다.
그렇다면, 예외 연쇄(exception chaining)을 사용하는 것이 좋다.
예외 연쇄란 문제의 근본 원인(cause)인 저수준 예외를 고수준 예외에 실어 보내는 방식이다.


예시

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

대부분의 표준 예외는 예외 연쇄용 생성자를 갖추고 있다.


적절하게 사용하기

무턱대고 예외를 전파하기 보다는 가능하다면 저수준 메서드가 반드시 성공하도록 하여
아래 계층에서는 예외가 발생하지 않도록 하는 것이 최선이다.


차선책

아래 계층에서의 예외를 피할 수 없다면, 상위 계층에서 그 예외를 조용히 처리하여 api 호출자에까지 전파하지 않는 방법이 있다.



75. 예외의 상세 메시지에 실패 관련 정보를 담자.

예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 스택 추적 정보를 자동으로 출력한다.
스택 추적은 예외 객체의 toString 메서드를 호출해 얻는 문자열이다.

예외의 toString 메서드에 실패 원인에 관한 정보를 가능한 한 많이 담아 반환하는 일은 아주 중요하다.


실패의 순간 포착하기

실패의 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 메세지에 담아야 한다.
예컨대 IndexOutOfBoundsException의 상세 메세지는 범위의 최소, 최대
그리고 그 범위를 벗어난 인덱스 값을 모두 담아야 한다.
그래야 이 메세지를 보고 무엇을 고쳐야 할지를 분석하는 데 도움이 된다.


실패 메세지

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



76. 가능한 한 실패 원자적으로 만들자.

검사 예외를 던진 경우라면 호출자가 오류 상태를 복구할 수 있을 테니 특히 더 유용하다.
호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다.
이러한 특성을 실패 원자적이라고 한다.

메서드를 실패 원자적으로 만들기

가장 간단한 방법은 불변 객체로 설계하는 것이다. 불변 객체는 실패 원자적이다.
메서드가 실패하면 새로운 객체가 만들어지지 않을 수는 있으나, 기존 객체가 불안정한 상태에 빠지는 일은 결코 없다.

가변 객체는 어떻게 하면 좋을까? 가장 흔한 방법은 작업 수행에 앞서 매개변수의 유효성을 검사하는 것이다.
객체의 내부 상태를 변경하기 전에 잠재적 예외의 가능성을 걸러낼 수 있는 방법이다.

public Object pop() {
	if (size == 0)
		throw new EmptyStackException();
	Object result = elements[--size];
	elements[size] = null; // 다 쓴 참조 해제
	return result;
}

이 메서드는 처음의 if문에서 size의 값을 확인하여 0이면 바로 예외를 던진다.



© 2022 Hyerin. All rights reserved.