필요 없는 검사 예외 사용은 피하자

2021-09-08

검사 예외(CheckedException)

검사 예외를 싫어하는 자바 개발자가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다.

결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리, 검사 예외는 발생한 문제를 프로그래머가 처리하여 안전성을 높이게끔 해준다.

물론, 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 된다.

어떤 메서드가 검사 예외를 던질 수 있다고 선언하면 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야만 한다.

어느 쪽이든 API 사용자에게 부담을 준다.

떠구나 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바 8부터는 부담이 더욱 커졌다.

컴파일 안됨 - 스트림 안에서 CheckedException을 던질 수 없다.

public List<Class> getClasses() throws ClassNotFoundException {
  return Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
    .map(className -> Class.forName(className))
    .collect(Collectors.toList());
}

ClassNotFoundException 은 CheckedException이다.

스트림안에서는 이 에러를 스트림 안에서 던지거나, 그대로 상위 메서드로 전달을 하지 못한다.

비검사 예외가 좋은 경우

API를 제대로 사용해도 발생할 수 있는 예외이거나, 개발자가 의미 있는 조치를 취할 수 있는 경우라면 이 정도 부담쯤은 받아들일 수 있을 것이다.

그러나 둘 중 어디에도 해당하지 않는다면 비검사 예외를 사용하는 게 좋다.

검사 예외 회피하기

검사 예외를 회피하는 가장 쉬운 방법은 적절한 결과 타입을 담은 옵셔널을 반환하는 것이다.

검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환하면 된다.

이 방식의 단점이라면 예외가 발생한 이유를 알려주는 부가 정보를 담을 수 없다는 것이다.

반면, 예외를 사용하면 구체적인 예외 타입과 그 타입이 제공하는 메서드들을 활용해 부가 정보를 제공할 수 있다.

또 다른 방법으로, 검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 바꿀 수 있다.

이 방식에서 첫 번째 메서드는 예외가 던져질지 여부를 boolean 값으로 반환 한다.

검사 예외를 던지는 메서드 - 리팩터링 전

try {
  obj.action(args);
} catch (TheCheckedException e) {
  
}

리팩터링 하면 다음과 같이 된다.

상태 검사 메서드와 비검사 예외를 던지는 메서드 - 리팩터링 후

if (obj.actionPermitted(args)) {
  obj.action(args)
} else {
  
}

이 리팩터링을 모든 상황에 적용할 수는 없다. 그래도 적용할 수만 있다면 더 쓰기 편한 API를 제공할 수 있다.

리팩터링 후의 API가 딱히 더 아름답진 않지만, 더 유연한 것은 확실하다.

프로그래머가 이 메서드가 성공하리라는 걸 안다거나, 실패 시 스레드를 중단하길 원한다면 다음처럼 한 줄로 작성해도 무방하다.

obj.action(args);

이 한줄 짜리 호출 방식이 주로 쓰일 거로 판단되면 리팩터링하는 편이 바람직하다.

한편, actionPermitted 는 상태 검사 메서드에 해당하므로 예외는 진짜 예외 상황에만 사용하자 글 에서 말한 단점도 그대로 적용되니 주의해야 한다.

즉, 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인에 의해 상태가 변할 수 있다면 이 리팩터링은 적절하지 않다.

actionPermittedaction 호출 사이에 객체의 상태가 변할 수 있기 때문이다.

또한 actionPermittedaction 메서드의 작업 일부를 중복 수행한다면 성능에서 손해이니, 역시 이 리팩터링이 적절하지 않을 수 있다.