티스토리 뷰

예외는 예외 상황에서 쓸 의도로 설계되었다. 
예외는 오직 예외 상황에서만 써야 한다.

 

🙄 예외는 오직 예외 상황에서만 써야 한다.

예외는 절대로 일상적인 제어 흐름용으로 쓰여선 안 된다.

예외를 사용해서 성능이 좋아지더라도 자바 플랫폼이 꾸준히 개선되고 있으니 최적화로 얻은 상대적인 성능 우위가 오래가지 않을 수 있다.

반면 과하게 영리한 기법에 숨겨진 미묘한 버그의 폐해와 어려워진 유지보수 문제는 계속 이어질 것이다.

 

 

 

😊 잘 설계된 API -> 예외를 사용할 일이 X

잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다.

특정 상태에서만 호출할 수 있는 '상태 의존적' 메서드를 제공하는 클래스는 '상태 검사' 메서드도 함께 제공해야 한다.

( Iterator 인터페이스의 next와 hasNext가 각각 상태 의존적 메서드와 상태 검사 메서드에 해당한다)

 

별도의 상태 검사 메서드 덕분에 다음과 같은 표준 for 관용구를 사용할 수 있다.

for (Iterator<Foo> i = Collection.iterator() ; i.hasNext(); ){
	Foo foo = i.next();
    ...
}

 

Iterator가 hasNext를 제공하지 않았다면 그 일을 클라이언트가 대신해야만 했다.

hasNext와 같은 상태 검사 메서드도 제공해야 한다.

List<Car> cars = new ArrayList<>();
try{
	Iterator<Car> i = cars.iterator();
    while(true){
    	Car car = i.next();
    }
} catch(NoSuchElementException e){
}

위와 같은 방법으로 순회하면 안 된다.

반복문에 예외를 사용하면 장황하고 헷갈리며 속도도 느리고, 엉뚱한 곳에서 발생한 버그를 숨기기도 한다.

 

상태 검사 메서드 대신 빈 옵셔널이나 null 같은 특수한 값을 반환하게 하는 방법도 있다.

상태 검사 메서드, 옵셔널, 특정 값 중 하나를 선택하는 지침 몇 가지이다.

 

1. 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인으로 상태가 변할 수 있다 옵셔널이나 특정 값을 사용한다. 상태 검사 메서드와 상태 의존적 메서드 호출 사이에 객체의 상태가 변할 수 있기 때문이다.

2. 성능이 중요한 상황에서 상태 검사 메서드가 상태 의존적 메서드의 작업 일부를 중복 수행한다면 옵셔널이나 특정 값을 선택한다.

3. 다른 모든 경우엔 상태 검사 메서드 방식이 조금 더 낫다고 할 수 있다. 가독성이 살짝 더 좋고, 잘못 사용했을 때 발견하기가 쉽다. 상태 검사 메서드 호출을 깜빡 잊었다면 상태 의존적 메서드가 예외를 던져 버그를 확실히 드러낼 것이다. 반면 특정 값은 검사하지 않고 지나쳐도 발견하기가 어렵다.

 

 

💡 정리

예외는 예외 상황에서 쓸 의도로 설계되었다.

따라서 정상적인 제어 흐름에서는 사용하면 안 되며, 이를 프로그래머에게 강요하는 API를 만들어서도 안 된다.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/11   »
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
글 보관함