예외의 추상화

• 수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 수 있다.
• 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 일어나는 일이다.
• 저수준 예외를 그대로 던질 경우 단순히 개발자를 당황시키는데 그치지 않고, 내부 구현 방식을 드러내게 되어 윗 레벨 API를 오염시킨다.
  • 만약 다음 릴리스에서 구현 방식을 바꾸면 또 다른 저수준의 예외가 던져져 기존의 예외를 처리하던 클라이언트 프로그램을 깨지게 할 수도 있다.
• 이런 문제를 피하려면 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다. 이를 예외 번역이라고 한다.

추상화의 예시

public E get(int index) {
		ListIterator<E> iter = listIterator(index);
		
		try {
				return iter.nextr();
		} catch(NoSuchElementException e) {
				throw new IndexOutOfBoundsException("index : " + index);
		}
}

• 해당 코드는 AbstractSequentialList에서 수행하는 예외 번역(추상화)의 예제이다.
• NoSuchElementException을 IndexOutOfBoundsException으로 변환하여 던저주는 것을 확인할 수 있다.
• 하지만 예외를 번역할 때 저수준 예외가 디버깅에 도움이 될 수 있다. 이럴 때는 Exception Chaning을 사용하는 것이 좋다.
  • Exception Chaning은 문제의 근본 원인인 저수준 예외를 고주순 예외에 실어 보내는 방식이다. 그러면 별도의 접근자 메서드를 통해 필요하면 언제든 저수준 예외를 꺼내볼 수 있다.

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

• 대부분의 표준 예외는 예외 연쇄용 생성자를 갖추고 있으며 그렇지 않은 예외라도 Throwable의 initCause() 메서드를 이용해 원인을 직접 못박을 수 있다.
• 예외 연쇄는 문제의 원인을 getCause() 메서드로 접근할 수 있게 해주며 원인과 고수준 예외의 스택 추적 정보를 잘 통합해준다.

2. 하지만 미리 잘 만들어 놓아야 한다.

• 무턱대고 저수준 예외를 전파하는 것 보다 예외 번역이 우수한 방법이지만 그렇다고 남용해서는 곤란하다.
  • 애초에 저수준 메서드가 반드시 성공하도록 잘 구현하여 아래 계층에서 예외가 발생하지 않도록 하는 것이 최선이다.
• 때로는 상위 계층 메서드의 매개변수 값을 아래 계층 메서드로 건네기 전에 미리 검사하는 바업ㅂ으로 이런 목적을 달성할 수 있다.
  • 즉 파라미터들을 미리 한 번 validation을 진행해 문제가 없는지 상위 계층에서 한 번 체크를 해보는 것이라고 할 수 있다.
• 만약 그렇게 할 수 없다면, 상위 계층에서 그 예외를 조용히 처리하여 문제 자체를 API 호출자에게까지 전파하지 않는 방법이 있다.
• 이 경우 발생한 예외는 로깅 기능을 활용하여 기록해두면 좋다. 그렇게 하면 클라이언트 코드와 사용자에게 문제를 전파하지 않으면서도 프로그래머가 로그를 분석해 추가 조치를 취할 수 있게 해준다.