Java의 Exception 전략

최근에 Java로 프로젝트를 진행하면서 지금까지 예외를 잘못된 방법으로 사용하고 있었다는 것을 인지했다. Effective Java를 읽은 후 지향해야 될 Exception 전략을 정리해본다.

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

잘못된 상황의 예외 사용은
- JVM의 최적화를 방해한다.
- 실제 예외 상황 발생에 대한 디버깅이 하기 힘들어진다.
잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다.
- ‘상태 의존적’ 메서드를 제공하는 클래스는 ‘상태 검사’ 메서드(또는 옵셔널이나 특수한 값)도 함께 제공하는 것이 좋다.
  - 멀티 스레딩으로 상태 검사 메서드와 상태 의존적 메서드 호출 사이에 객체의 상태가 변할 수 있는 경우 옵셔널이나 특정 값을 사용한다.
  - 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업의 일부를 중복 수행한다면 옵셔널이나 특정 값을 선택한다.
  - 다른 모든 경우에는 상태 검사 메서드 방식이 낫다. 가독성이 살짝 더 좋고, 잘못 사용했을 때 발견하기가 쉽다.

호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용한다.
프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자. 런타임 예외는 대부분 전제조건을 만족하지 못했을 때 발생한다.(ArrayIndexOutOfBoundsException)
검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하면 안된다.

검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높이게 도와준다.
하지만 과하게 사용하면 오히려 쓰기 불편한 API가 된다.
API를 제대로 사용할 때도 발생할 수 있는 예외거나, 프로그래머가 의미 있는 조치를 취할 수 있을 경우에만 사용해야된다.
검사 예외를 피하는 방법
- 옵셔널을 반환한다. 하지만 이 방법은 예외가 발생한 이유를 알려주는 부가 정보를 담을 수 없다.
- 상태 검사 메서드와 비검사 예외를 던지는 메서드로 쪼갠다. 하지만 이 방법은 모든 상황에 적용할 수는 없다.

표준 예외를 사용한 API가 다른 사람이 익히고 사용하기 쉬워진다.
예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다.
널리 재사용되는 표준 예외
- IllegalArgumentException: 허용하지 않은 값이 인수로 건네졌을 때(null은 따로 NullPointerException으로 처리)
- IllegalStateException: 객체가 메서드를 수행하기에 적절하지 않은 상태일 때
- NullPointerException: null을 허용하지 않는 메서드에 null을 건넸을 때
- IndexOutOfBoundsException: 인덱스가 범위를 넘어섰을 때
- ConcurrentModificationException: 멀티 스레드 환경에서 허용하지 않는 동시 수정이 발견됐을 때
- UnsupportedOperationException: 호출한 메서드를 지원하지 않을 때
IllegalArgumentException과 IllegalStatementException 중에 고민이 되는 경우가 있다. 이럴 때는, 인수 값이 무엇이든 어차피 실패했을거라면 IllegalStateException을, 그렇지 않으면 IllegalArgumentException을 던진다.

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