이펙티브 자바, 쉽게 정리하기 - item 71. 필요 없는 검사 예외(checked error) 사용은 피하라

이펙티브 자바, 쉽게 정리하기 - item 71. 필요 없는 검사 예외(checked error) 사용은 피하라

검사 예외의 단점

• try-catch 혹은 throws 를 강제한다.
  • 이 과정에서 많은 개발자들이 귀찮다는 이유로 잘못된 예외 처리 로직을 작성하거나 예외처리 로직에서 아무 행위도 하지 않기도 한다.
• 검사 예외가 발생하는 메서드는 스트림 안에서 해당 메서드를 직접 사용할 수 없다.

단, 프로그래머가 이 검사 예외로 인해 의미있는 조치를 취할 수 있다면 괜찮은 조치일 수도 있다.

예외 상황에 대처하지 못하는 경우의 예

try {
  // ...
} catch (TheCheckedException e) {
  throw new AssertionError(); // 일어날 수 없다!
}

try {
  // ...
} catch (TheCheckedException e) {
  e.printStackTrace(); // 이런, 우리가 졌다!
  System.exit(1);
}

• 개발자가 검사 예외를 저렇게 처리한다면, 차라리 비검사 예외로 처리하는 것이 나을 것이다.

검사 예외를 회피하는 가장 쉬운 방법 1: 옵셔널

• 적절한 결과 타입을 담은 옵셔널을 반환하는 것이다.
• 검사 예외를 던지는 대신 빈 옵셔널을 반환하는 방식을 사용하는 것이다.
• 단, 옵셔널을 사용하면, 예외가 발생한 이유를 알려주는 부가정보는 담을 수 없을 것이다.
  • 예외를 사용하면, 구체적인 예외 타입과 메서드를 활용해 부가정보를 담을 수 있다.

검사 예외를 회피하는 가장 쉬운 방법 2: 메서드를 2개로 쪼개기

• 메서드를 2개로 쪼개서 비검사 예외로 바꿀 수 있다.
• 예외가 던져질지 여부를 boolean 으로 처리한 뒤에 if 문으로 판단하는 것이다.
  • catch 로 가는 것이 아니라 if (false) { ... } 로 가는 것이다.

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

try {
  obj.action(args);
} catch (TheCheckedException e) {
  // 예외 복구
}

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

if(obj.actionPermitted(args)) {
  obj.action(args);
} else {
  // 예외 복구
}

• 리팩터링 후가 딱히 아름다운 코드는 아니어도, 훨씬 더 유연하다.
• 모든 상황에 적용할 수 있는 리팩터링은 아니다.
• 실패시 스레드를 중단시키기 원하면 obj.action(args); 와 같이 한줄로도 가능하다.
  • 이 한줄짜리 호출방식이 주로 쓰일 것 같다면, 리팩터링하는 편이 바람직하다.
• actionPermitted() 이 여러 스레드에서 동시에 접근된다면, 이 리팩터링은 적절치 않다.
  • actionPermitted() 와 action() 사이에 객체 상태가 변할 수 있다.
  • 만일, actionPermitted() 와 action() 에 중복 수행이 있다면, 성능에서 손해라 역시 이 리팩터링은 적절치 않을 수도 있다.

핵심 정리

• 검사 예외는 필요한 곳에서는 프로그램의 안정성을 높여주는 장점이 있다.
  • 필요하지 않은 곳에 쓰이면 클라이언트의 코드를 복잡하게만 만든다.
• 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자.
• 복구가 가능하면서 호출자가 그 처리를 해주길 바라면, 옵셔널을 반환해도 될지 고민하자.
  • 옵셔널만으로 충분한 정보를 제공할 수 없다면 검사 예외를 던지자.