- 한줄 결론 : 예외는 오직 예외 상황에서만 사용해야 된다. 절대로 일상적인 제어 흐름용으로 사용하지말자.
// 잘못된 예시
try {
int i = 0;
while(true)
range[i++].climb();
} cattch (ArrayIndexOutOfBoundsException e){
}// 올바른 예시 - 훨씬 이해가 쉬움
for(Mountain m : range)
m.climb();- 잘못된 추론 : jvm의 배열 접근시 경계 검사 & 반복문의 경계 검사라는 중복된 일을 하므로 하나 생략했다고함.
- 잘못된점
- 예외는 예외 상황에서만 써야한다. 예외로 처리 하는건 오히려 느림.
- 코드를 try-catch 블록 안에 넣으면 jvm이 적용할 수 있는 최적화가 제한됨
- 배열 순회하는 표준 관용구는 앞서 걱정한 중복 검사를 수행하지 않음. jvm이 알아서 최적화
- API를 설계할때 클라이언트가 정상적인 제어흐름에서 예외를 사용할 일이 없게 하자.
그대신 특정 상태에서만 호출할 수 있는 '상태 의존적' 메서드를 제공하는 클래스는 '상태 검사' 메서드를 제공하자.
- ex) Iterator 인터페이스의
next,hasNext는 각각 상태 의존 메서드, 상태 검사 메서드다.
선택 기준은
- (1) 옵셔널이나 특정 값 사용할때는?
- 언제 ? 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인으로 상태가 변할 수 있다면.
- 이유 ? 상태 검사 메서드, 상태 의존적 메서드 호출 사이에 객체 상태가 변할 수 있음.
- (2) 옵셔널이나 특정값 사용할때는?
- 언제? 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업을 일부 중복 수행한다면
- (3) 다른 모든 경우는 상태 검사 메서드 방식이 낫다.
- 잘못 사용했을때 예외를 던져 버그를 확실히 알 수 있다.