요약
•
검사 예외는 여러 장단점이 있으니 잘 고려해서 신중하게 사용하자.
검사 예외의 장단점
•
검사 예외는 제대로 활용하면 API와 프로그램의 질을 높일 수 있다.
•
결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리, 검사 예외는 프로그래머가 발생한 문제를 직접 처리하여 안전성을 높일 수 있다.
•
하지만 메서드에서 검사 예외를 던질 수 있다고 선언되어 있으면 이를 호출하는 코드에서는 catch 블록으로 해당 예외를 잡아서 처리하거나 더 바깥으로 전파해야만 하기 때문에, 검사 예외를 과하게 사용하면 쓰기 불편한 API가 될 수 있다.
•
이에 더해 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없다는 단점도 있다.
검사 예외는 필요한 곳에만 사용하기
•
API를 제대로 사용해도 발생할 수 잇는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있다면 검사 예외를 사용해도 괜찮다.
•
하지만 위 두 사항에 해당되지 않는다면 비검사 예외를 사용하는 것이 좋다.
•
특정 메서드에서 검사 예외를 추가했을 때, 기존에 다른 검사 예외를 던지고 있는 상황이라면 catch 블록 한 개만 추가된다. 하지만 검사 예외가 추가되어 단 한개의 검사 예외만 존재하는 경우라면, 오직 그 예외 하나 때문에 try-catch 블록을 추가해야하고 스트림에서 사용하지 못하게 된다.
•
검사 예외를 회피하는 가장 쉬운 방법은 적절한 결과 타입을 담은 옵셔널을 반환하는 것이다. 이로 인한 단점은 예외가 발생한 이유에 대한 부가정보를 담을 방법이 없다는 것이다. 반면, 그냥 런타임 예외를 발생시키면 구체적인 예외 타입과 그 타입이 제공하는 메서드들을 통해 부가 정보를 제공할 수 있다.
•
또 다른 방법으로는 검사 예외를 던지는 메서드를 2개로 쪼개 예외가 던져지는가에 대한 여부를 boolean으로 확인하는 방법이다.
// 리팩토링 전
try {
obj.action(args);
} catch (TheCheckedException e) {
... // 예외 상황에 대한 대처
}
// 리팩토링 후
if (obj.actionPermitted(args)) {
obj.action(args);
} else {
... // 예외 상황에 대한 대처
}
Java
복사
•
이 방법은 더 쓰기 편하고 유연하게 사용할 수 있지만, 이전 아이템에서 언급한 상태 검사 메서드의 단점을 그대로 적용되니 주의해야 한다.