복잡한뇌구조마냥

[JAVA] Effective Java - 표준 예외를 사용하라 (72) 본문

BE/JAVA

[JAVA] Effective Java - 표준 예외를 사용하라 (72)

지금해냥 2025. 9. 4. 11:19

✅ 정리 (사용자 이해 + 보강)

1. 표준 예외 재사용의 장점

  • 가독성: 많은 개발자가 공통된 의미로 이해 가능 → API 사용성이 좋아진다.
  • 효율성: 불필요하게 예외 클래스를 늘리지 않아 메모리 사용량/클래스 적재 시간 감소.
  • 일관성: “이 상황에선 이 예외”라는 패턴이 잡히면, 코드 독해와 디버깅이 쉬워진다.
  • 문서화 편의: 표준 예외는 이미 잘 정의되어 있어 문서에 적기만 해도 충분하다

2. 자주 쓰이는 표준 예외

예외 클래스 사용 상황
IllegalArgumentException 메서드에 넘긴 인수 값이 부적절할 때
IllegalStateException 객체의 상태가 메서드 수행에 적합하지 않을 때
NullPointerException null을 허용하지 않는 메서드에 null을 전달했을 때
IndexOutOfBoundsException 시퀀스 인덱스가 범위를 벗어났을 때
ConcurrentModificationException 단일 스레드 전용 객체를 여러 스레드가 수정하려 할 때
UnsupportedOperationException 요청한 동작을 객체가 지원하지 않을 때
ArithmeticException 산술 오류 (0으로 나눔, 수학적 불가능 연산 등)
NumberFormatException 문자열을 숫자로 변환 실패할 때

3. 쓰지 말아야 할 예외

  • Exception, RuntimeException, Throwable, Error
    → 직접 던지지 말고 추상 클래스처럼 간주해야 한다.
    → 너무 포괄적이라 구체적인 오류 맥락을 전달할 수 없음.

4. 다른 상황에 활용 가능한 표준 예외

  • ArithmeticException: 수학 연산 오류(예: 0으로 나눔, 복소수 연산 오류).
  • NumberFormatException: 문자열을 수치 타입으로 변환 실패.

5. 예외 선택이 애매한 경우

  • 예: 카드 뽑기 메서드에서, 남은 카드 수보다 큰 숫자를 인수로 받았을 때
    • IllegalArgumentException: 인수가 잘못된 경우 (남은 카드 수보다 클 때만 실패).
    • IllegalStateException: 인수와 무관하게, 남은 카드 수 자체가 0이면 항상 실패.
  • 👉 즉, 인수가 원인인지 상태가 원인인지에 따라 선택.

6. 예외 설계 관련 추가 고려사항

  • 예외는 직렬화 가능해야 한다:
    → 새로운 예외를 정의하면 직렬화까지 고려해야 해서 부담이 크다.
  • 불필요한 사용자 정의 예외는 피하라:
    → 표준 예외로 충분히 표현 가능하다면, 새 예외를 만들지 않는 게 바람직하다.
  • API 문서를 확인해, 예외가 어떤 상황에서 던져지는지 의도와 맥락이 부합할 때만 재사용해야 한다.

📌 사용자 정의 예외는 언제?

  • 표준 예외로 상황을 설명하기 어려울 때만 정의한다.
  • 도메인 특화 예외 예시: InsufficientFundsException, CardNotFoundException.
  • 이 경우에도 가능하다면 IllegalArgumentException 같은 표준 예외 계층을 상속해 일관성 유지.

📌 예외와 문서화

  • API 문서에 반드시 @throws 태그로 명시해야 한다.
  • 예:
 
/**
 * 지정된 인덱스의 요소를 반환한다.
 *
 * @throws IndexOutOfBoundsException 인덱스가 범위를 벗어난 경우
 */
E get(int index)
  • 표준 예외는 이미 맥락이 정해져 있어 문서만 읽어도 이해가 쉽다.

✅ 결론

자바의 표준 예외를 적극적으로 재사용하라.

  • 가장 흔한 예외는 IllegalArgumentException, IllegalStateException, NullPointerException.
  • 표준 예외로 설명할 수 없다면, 그때만 도메인 특화 예외를 정의하라.
  • 어떤 예외를 던지는지는 반드시 API 문서로 명확히 밝혀라.
새로운 예외를 만드는 건 마지막 수단이며, 표준 예외가 충분히 맥락을 설명할 수 있다면 그대로 활용하는 게 가장 바람직하다.

 

LIST