자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공한다.
표준 예외를 재사용하면 얻는 점이 많다.
- 다른 사람이 익히고 사용하기 쉬워진다는 것이다. 많은 프로그래머에게 이미 익숙해진 규약을 그대로 따르기 때문이다.
- 낯선 예외를 사용하지 않으므로 읽기 쉽다.
- 예외 클래스 수가 적을수록 메모리 사용량도 줄고, 클래스를 적재하는 시간도 적게 걸린다.
널리 사용되는 표준 예외는 다음과 같다.
| 예외 | 주요 쓰임 |
|---|---|
| IllegalArgumentException | 허용하지 않는 값이 인수로 건네졌을 때 (단, null은 NullPointerException으로 처리) |
| IllegalStateException | 객체가 메서드르 수행하기에 적절하지 않은 상태일 때 |
| NullPointerException | null을 허용하지 않는 메서드에 null을 건넸을 때 |
| IndexOutOfBoundsException | 인덱스가 범위를 넘어섰을 때 |
| ConcurrentModificationException | 허용하지 않는 동시 수정이 발견됐을 때 |
| UnsupportedOperationException | 호출한 메서드를 지원하지 않을 때 |
Exception, RuntimeException, Throwable, Error는 직접 재사용하지 말자.
이 클래스들은 추상 클래스라고 생각하자. 이 예외들은 다른 예외들의 상위 클래스이므로, 즉 여러 성격의 예외들을 포괄하는 클래스이므로 안정적으로 테스트할 수 없다.
'주요 쓰임'이 상호 배타적이지 않기 때문에, 종종 재사용할 예외를 선택하기 어려울 때도 있다. 예를 들어 IllegalArgumentException과 IllegalStateException 둘 중에 어떤 예외를 재사용해야 할지 고민할 수 있다. 일반적인 규칙은 이렇다. 인수 값이 무엇이었든 어차피 실패했을 거라면 IllegalStateException을, 그렇지 않으면 IllegalArgumentException을 던지자.
상황에 부합한다면 항상 표준 예외를 재사용하자. 이때 API 문서를 참고해 그 예외가 어떤 상황에서 던져지는지 꼭 확인해야 한다. 예외의 이름뿐 아니라 예외가 던져지는 맥락도 부합할 때만 재사용한다.
더 많은 정보를 제공하길 원한다면 표준 예외를 확장해도 좋다. 단, 예외는 직렬화할 수 있다는 사실을 기억하자(직렬화에는 많은 부담이 따른다). 이 사실만으로도 나만의 예외를 새로 만들지 않아야 할 근거로 충분할 수 있다.
백엔드 개발자