아이템72 표준 예외를 사용하라

무엇이 좋아지나?

• 여러분의 API가 다른 사람이 익히고 사용하기 쉬워진다는 것이다.
  많은 프로그래머에게 이미 익숙해진 규약을 그대로 따르기 때문이다.
• 예외클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다.

사용하면 좋은 예외들

IllegalArgumentException

호출자가 인수로 부적절한 값을 넘길 때 던지는 예외로, 예를 들어 반복 횟수를 지정하는 매개변수에 음수를 건넬 때 쓸 수 있다.

IllegalStateException

이 예외는 대상 객체의 상태가 호출된 메서드를 수행하기에 적합하지 않을 때 주로 던진다. 예컨대 제대로 초기화되지 않은 객체를 사용하려 할 때 던질 수 있다.

NullPointerException

메서드가 던지는 모든 예외를 잘못된 인수나 상태라고 뭉뚱그릴 수도 있겠지만, 그중 특수한 일부는 따로 구분해 쓰는 게 보통이다. null 값을 허용하지 않는 메서드에 null을 건네면 관례상 IllegalArgumentException이 아닌 NullPointerException을 던진다.

IndexOutOfBoundsException

비슷하게, 어떤 시퀀스의 허용 범위를 넘는 값을 건넬 때도 IllegalArgumentException보다는 IndexOutOfBoundsException 을 던진다.

ConcurrentModificationException

단일 스레드에서 사용하려고 설계한 객체를 여러 스레드가 동시에 수정하려 할 때 던진다(외부 동기화 방식으로 사용하려고 설계한 객체도 마찬가지다). 사실 동시 수정을 확실히 검출할 수 있는 안정된 방법은 없으니, 이 예외는 문제가 생길 가능성을 알려주는 정도의 역할로 쓰인다.

UnsupportedOperationException

이 예외는 클라이언트가 요청한 동작을 대상 객체가 지원하지 않을 때 던진다. 대부분 객체는 자신이 정의한 메서드를 모두 지원하니 흔히 쓰이는 예외는 아니다.

보통은 구현하려는 인터페이스의 메서드 일부를 구현할 수 없을 때 쓰는데, 예컨대 원소를 넣을 수만 있는 List 구현체에 대고 누군가 remove 메서드를 호출하면 이 예외를 던질 것이다.

주의점

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

이 클래스들은 추상 클래스라고 생각하길 바란다. 이 예외들은 다른 예외들의 상위 클래스이므로, 즉 여러 성격의 예외들을 포괄하는 클래스이므로 안정적으로 테스트할 수 없다.

더 많은 정보를 제공하길 원한다면 표준 예외를 확장해도 좋다.

단, 예외는 직렬화할 수 있다는 사실을 기억하자(12장). (직렬화에는 많은 부담이 따르니) 이 사실만으로도 나만의 예외를 새로 만들지 않아야 할 근거로 충분할 수 있다.