티스토리 뷰
숙련된 프로그래머는 그렇지 못한 프로그래머보다 더 많은 코드를 재사용합니다.
예외도 마찬가지로 재사용하는 것이 좋으며, 자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공합니다.
표준 예외를 재사용하면 얻는 게 많습니다.
그 중 최고는 여러분의 API가 다른 사람이 익히고 사용하기 쉬워진다는 것이죠.
많은 프로그래머에게 이미 익숙해진 규약을 그대로 따르기 때문입니다.
여러분의 API의 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다는 장점도 큽니다.
마지막으로, 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸립니다.
가장 많이 재사용되는 예외는 IllegalArgumentException입니다. (아이템 49)
호출자가 인수로 부적절한 값을 넘길 때 던지는 예외로, 예를 들어 반복 횟수를 지정하는 매개변수에 음수를 건넬 때 쓸 수 있습니다.
IllegalStateException도 자주 재사용됩니다.
이 예외는 대상 객체의 상태가 호출된 메서드를 수행하기에 적합하지 않을 때 주로 던집니다.
예컨대 제대로 초기화되지 않은 객체를 사용하려 할 때 던질 수 있습니다.
메서드가 던지는 모든 예외를 잘못된 인수나 상태라고 뭉뚱그릴 수도 있겠지만, 그 중 특수한 일부는 따로 구분해 쓰는 게 보통입니다.
null 값을 허용하지 않는 메서드에 null을 건네면 관례상 IllegalArgumentException이 아닌 NullPointerException을 던집니다.
비슷하게, 어떤 시퀀스의 허용 범위를 넘는 값을 건넬 때도 IllegalArgumentException보다는 IndexOutOfBoundsException을 던집니다.
재사용하기 좋은 또 다른 예외인 ConcurrentModificationException은 단일 스레드에서 사용하려고 설계한 객체를 여러 스레드가 동시에 수정하려 할 때 던집니다.
(외부 동기화 방식으로 사용하려고 설계한 객체도 마찬가지입니다.)
사실 동시 수정을 확실히 검출할 수 있는 안정된 방법은 없으니, 이 예외는 문제가 생길 가능성을 알려주는 정도의 역할로 쓰입니다.
마지막으로 소개할 표준 예외는 UnsupportedOperationException입니다.
이 예외는 클라이언트가 요청한 동작을 대상 객체가 지원하지 않을 때 던집니다.
대부분 객체는 자신이 정의한 메서드를 모두 지원하니 흔히 쓰이는 예외는 아닙니다.
보통은 구현하려는 인터페이스의 메서드 일부를 구현할 수 없을 때 쓰는데, 예컨대 원소를 넣을 수만 있는 List 구현체에 대고 누군가 remove 메서드를 호출하면 이 예외를 던질 것입니다.
Exception, RuntimeException, Throwable, Error는 직접 재사용하지 맙시다.
이 클래스들은 추상 클래스라고 생각하길 바랍니다.
이 예외들은 다른 예외들의 상위 클래스이므로, 즉 여러 성격의 예외들을 포괄하는 클래스이므로 안정적으로 테스트할 수 없습니다.
다음 표에 지금까지 설명한 널리 재사용되는 예외들을 정리했습니다.
이상이 확실히 가장 흔하게 재사용되는 예외지만, 다른 상황에서는 다른 예외도 재사용할 수 있습니다.
예컨대 복소수나 유리수를 다루는 객체를 작성한다면 ArithmeticException이나 NumberFormatException을 재사용할 수 있을 것입니다.
상황에 부합한다면 항상 표준 예외를 재사용합시다.
이 때 API 문서를 참고해 그 예외가 어떤 상황에서 던져지는지 꼭 확인해야 합니다.
예외의 이름뿐 아니라 예외가 던져지는 맥락도 부합할 때만 재사용합니다.
더 많은 정보를 제공하길 원한다면 표준 예외를 확장해도 좋습니다.
단, 예외는 직렬화할 수 있다는 사실을 기억합시다.
이 사실만으로도 나만의 예외를 새로 만들지 않아야 할 근거로 충분할 수 있습니다.
앞서의 이미지로 정리한 '주요 쓰임'이 상호 배타적이지 않은 탓에, 종종 재사용할 예외를 선택하기가 어려울 때가 있습니다.
예를 들어 카드 덱을 표현하는 객체가 있고, 인수로 건넨 수만큼의 카드를 뽑아 나눠주는 메서드를 제공한다고 해봅시다.
🤔
이 때 댁에 남아 있는 카드 수보다 큰 값을 건네면 어떤 예외를 던져야 할까요?
인수의 값이 너무 크다고 본다면 IllegalArgumentException을, 덱에 남은 카드 수가 너무 적다고 본다면 IllegalStateException을 선택할 것입니다.
이런 상황에서의 일반적인 규칙은 이렇습니다.
인수 값이 무엇이었든 어차피 실패했을 거라면 IllegalStateException을, 그렇지 않다면 IllegalArgumentException을 던집시다.
'JAVA > 이펙티브 자바' 카테고리의 다른 글
아이템[74]. 메서드가 던지는 모든 예외를 문서화하라 (0) | 2022.05.22 |
---|---|
아이템[73]. 추상화 수준에 맞는 예외를 던져라 (0) | 2022.05.22 |
아이템[71]. 필요없는 CheckedException 사용은 피하라 (0) | 2022.05.19 |
아이템[70]. 복구할 수 있는 상황에는 CheckedException를, 프로그래밍 오류에는 런타임 예외를 사용하라 (0) | 2022.05.19 |
아이템[69]. 예외는 진짜 예외 상황에만 사용하라 (0) | 2022.05.19 |
- Total
- Today
- Yesterday
- 클린 아키텍처
- programmers
- kotest
- Kotlin
- 디자인 패턴
- 이팩티브 자바
- Algorithm
- Spring Boot
- 프로그래머스
- Spring
- AWS
- BOJ
- Java
- node.js
- 디자인패턴
- BAEKJOON
- JPA
- 객체지향
- 백준
- 테라폼
- 정규표현식
- 클린 코드
- 이펙티브 자바
- kkoon9
- Effective Java
- 코테
- C++
- MSA
- 알고리즘
- Olympiad
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |