Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |
Tags
- 데이터베이스 #try #이중
- 으
- 당근마켓
- Props
- npm
- &연산
- 컴포넌튼
- font-size
- 0.5px border
- 문서번호
- entity
- 0.25px border
- 타입스크립트
- 10px
- TypeScript
- 서버리스 #
- github
- ES5
- ZOOM
- 클론코딩
- jwt
- Websocket
- 1px border
- es6
- Strict
- 전역변수
- angular
- literal
- TS
- 0.75px border
Archives
- Today
- Total
복잡한뇌구조마냥
[JAVA] Effective Java - 표준 예외를 사용하라 (72) 본문
✅ 정리 (사용자 이해 + 보강)
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
'BE > JAVA' 카테고리의 다른 글
[JAVA] Effective Java - readObject 메서드는 방어적으로 작성하라 (88) (0) | 2025.09.15 |
---|---|
[JAVA] Effective Java - 프로그램의 동작을 스레드 스케줄러에 기대지 말라 (84) (0) | 2025.09.07 |
[JAVA] Effective Java - 일반적으로 통용되는 명명 규칙을 따르라 (68) (2) | 2025.09.01 |
[JAVA] Effective Java - 지역변수의 범위를 최소화하라 (57) (1) | 2025.08.31 |
[JAVA] Effective Java - 다중정의는 신중히 사용하라 (52) (0) | 2025.08.24 |