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

[corock]

표준 예외를 사용하면 좋은 점

• 작성한 API 가 다른 사람이 익히고 사용하기 쉬워집니다.
• API 클라이언트도 낯선 예외를 사용하지 않게 되어 읽기가 쉬워집니다.
• 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸립니다.

자주 재사용하는 예외 클래스 유형

IllegalArgumentException

호출자가 인수로 부적절한 값을 넘길 때 던지는 예외

• e.g. 반복 횟수를 지정하는 매개변수에 음수를 전달할 때
• cf. 아이템 49. 매개변수가 유효한지 검사하라 #115

IllegalStateException

대상 객체의 상태가 호출된 메서드를 수행하기에 적합하지 않을 때 던지는 예외

• e.g. 제대로 초기화되지 않은 객체를 사용하려 할 때

NullPointerException

null 값을 허용하지 않는 메서드에 null 을 건넸을 때 던지는 예외

IndexOutOfBoundsException

어떤 시퀀스의 허용 범위를 넘는 값을 건넬 때 던지는 예외

비교적 유명하지 않으나 재사용 시 유용한 예외 클래스 유형

ConcurrentModificationException

단일 스레드에서 사용하거나 외부 동기화 방식으로 사용하려고 설계한 객체를 여러 스레드가 동시에 수정하려 할 때 던지는 예외

• 동시 수정을 확실히 검출할 수 있는 안정된 방법은 없으니, 문제가 생길 가능성을 알려주는 정도의 역할

UnsupportedOperationException

클라이언트가 요청한 동작을 대상 객체가 지원하지 않을 때 던지는 예외

• 대부분 객체는 자신이 정의한 메서드를 모두 지원하니 흔히 쓰이는 예외는 아님
• 보통 구현하려는 인터페이스의 메서드 일부를 구현할 수 없을 때 사용
• e.g. 원소를 넣을 수만 있는 List 구현체에 대고 누군가 remove 메서드 호출 시 사용

java.lang 패키지에 있는 예외 소개

• ArithmeticException
• ArrayIndexOutOfBoundsException
• ArrayStoreException
• ClassCastException
• ClassNotFoundException
• CloneNotSupportedException
• EnumConstantNotPresentException
• IllegalAccessException
• IllegalArgumentException
• IllegalCallerException
• IllegalMonitorStateException
• IllegalStateException
• IllegalThreadStateException
• IndexOutOfBoundsException
• InstantiationException
• InterruptedException
• LayerInstantiationException
• NegativeArraySizeException
• NoSuchFieldException
• NoSuchMethodException
• NullPointerException
• NumberFormatException
• ReflectiveOperationException
• RuntimeException
• SecurityException
• StringIndexOutOfBoundsException
• TypeNotPresentException
• UnsupportedOperationException

주의사항

• Exception, RuntimeException, Throwable, Error 는 추상 클래스라고 생각하고, 직접 재사용하지 말 것
  • 여러 성격의 예외들을 포괄하는 다른 예외들의 상위 클래스이기 때문에 안정적으로 테스트할 수 없음
• API 문서를 참고해 그 예외가 어떤 상황에서 던져지는지 꼭 확인해야 함
  • 예외의 이름뿐만 아니라 예외가 던져지는 맥락(context)도 부합할 때만 재사용할 것
• 더 많은 정보를 제공하길 원한다면 표준 예외를 확장(extend)해도 좋으나, 예외는 직렬화할 수 있다는 것에 주의(12장)
  • cf. custom exception을 언제 써야 할까?
• 재사용할 예외를 선택하기가 어려울 때는 "알잘딱깔센" 하게 사용하자

회고

해당 아이템을 왜 언급했을까?

• 예외를 제대로 활용한다면 프로그램의 가독성, 신뢰성, 유지보수성이 높아진다.
• 하지만, 잘못 사용하면 반대의 효과만 나타나기 때문에 예외를 효과적으로 활용해야 한다.

So What?

• 안전한 프로그램을 만들기 위해 예외는 최대한 꼼꼼하게 하자는 주의였는데 자칫 남발할 수 있어 꼭 필요한 상황에만 하기로 했습니다.
• 한때 예외는 커스터마이징하는 것이 최고라고 생각한 적이 있었는데 이것 또한 역시 "기본에 충실하자" 라는 정신을 이어가기로 했습니다.

[Irisation23]

#172 해당 아이템을 다뤄보면서 느낀 점과 닮아 있는 것 같습니다.
예외를 상속해서 사용했던 과거가 많았는데, 이는 꼭 필요한 행위였나.. 다시금 돌이켜 보는 계기가 됐습니다.

어찌보면 표준 예외를 사용하라는 의미는 설계자가 그만큼 고민을 많이 했다는 반증이 아닐까 생각해봅니다.

만약 앞으로 누군가 커스텀 예외 쓸데 없이 하고 있는 모습이 보이면 싱글벙글 하면서 해당 주제 링크 달도록 하겠습니다. 😁

[JoisFe]

프로젝트를 하면서 예외처리할 경우가 많은데 해당 예외에 적합한 표준예외를 먼저 찾아봤어야 했는데 막무가내로 커스텀 예외 클래스를 만들었었는데, 반성하게 되는 주제입니다.

해당 주제와는 다르지만 어쩔 수 없이 커스텀 예외 클래스를 만들게 되고 그 수가 늘게 되면 관리하기 불편해지게 됩니다.
ENUM에 커스텀 예외들을 모아두고 관리하기도 했는데 예외 클래스가 더 많아지면 이 방법 또한 고민해보아야 한다는 한 시니어 개발자 분의 말씀을 들었습니다.

혹시 @corock 님은 어떻게 관리하시는지 혹은 어떤 방법이 괜찮은지 하신다면 공유해주시면 감사하겠습니다.

[JoisFe]

표준 예외를 사용하라 !!!
#101 -> 표준 함수형 인터페이스를 사용하라
#136 -> 최대한 표준 라이브러리를 사용하라