69. 예외는 진짜 예외 상황에만 사용하라
1278 단어 Effective JavaEffective Java
예외 상황
예외를 완전히 잘못 사용한 예
try{
int i = 0;
while(true)
range[i++].climb();
}catch (ArrayIndexOfBoundsException e){
}
위 코드는 잘못된 추론을 근거로 성능을 높이려고 하고 있다.JVM은 배열의 원소에 접근할 때마다 경계를 넘지 않는지 검사한다. 따라서 이 검사를 반복문에도 적용할 경우 같은 일이 중복되므로 하나를 생략한 것이다. 하지만 이 추론은 세 가지 근거에서 잘못됐다.
- 예외는 예외 상황에 쓸 용도로 설계되었기 때문에 JVM 구현자 입장에서는 명확한 검사만큼 빠르게 만들어야 할 동기가 약하다.
- 코드를 try-catch 블록 안에 넣으면 JVM이 적용할 수 있는 최적화가 제한된다.
- 배열을 순회하는 표준 관용구는 앞서 걱정한 중복 검사를 수행하지 않는다. JVM이 알아서 최적화해 없애준다.
예외는 예외적인 상황에만 써야한다. 절대로 일상적인 제어 흐름용으로 쓰여선 안된다. 이 원칙은 API 설계에도 적용된다. 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다. 특정 상태에서만 호출할 수 있는 상태 의존적 메서드를 제공하는 클래스는 상태 검사 메서드를 함께 제공해야 한다. iterator의 next와 hasNext가 그 예이다.
상태검사 메서드 대신 선택할 수 있는 방안도 몇개 있다. 올바르지 않은 상태일 때 빈빈 Optional 메서드나 return null 이 그 예이다. 이를 선택하는 다음 지침을 보자.
- 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인으로 상태가 변할 수 있다면 Optional이나 특정 값을 사용한다. 상태 검사 메서드와 상태 의존적 메서드 호출 사이에 객체의 상태가 변할 수 있기 때문이다.
- 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 중복 수행한다면 옵셔널이나 특정 값을 선택한다.
- 다른 모든 경우에는 상태 검사 메서드 방식이 조금 더 낫다고 할 수 있다. 가독성이 살짝 더 좋고, 잘못 사용했을 때 발견하기 쉽다. 상태 검사 메서드 호출을 잊었다면, 상태 의존적 메서드가 예외를 던져 버그를 확실히 드러낸다.
Author And Source
이 문제에 관하여(69. 예외는 진짜 예외 상황에만 사용하라), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@chullll/69.-예외는-진짜-예외-상황에만-사용하라저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)