[Effective Java] 필요 없는 검사 예외 사용은 피하라

검사 예외의 불편

• 검사 예외를 싫어하는 개발자가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 반면 사용이 과해지면 불편하기만 할 수도 있다.
• 검사 예외가 단 하나뿐이라면 오직 그 예외 때문에 API 사용자는 try 블록을 추가해야 하고 스트림에서 직접 사용하지 못하게 된다. 그러니 이런 상황이라면 검사 예외를 안 던지는 방법이 없는지 고민해볼 가치가 있다.

검사 예외 회피 방법

1. 비검사 예외

• API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우라면 이 정도 부담쯤은 받아들일 수 있을 것이다. 하지만 이 경우들이 아니라면, 비검사 예외를 사용하는 것이 좋다.

2. Optional

• 검사 예외를 회피하는 두 번째 방법은 적절한 결과 타입을 담은 옵셔널을 반환하는 것이다.
• 검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환하면 된다. 쉽다.
• 하지만 이 방식은 단점이 있다.
• 예외가 발생한 이유를 알려주는 부가 정보를 담을 수 없다는 점이다. (예외를 사용하면 구체적인 예외 타입과 그 타입이 제공하는 메서드들을 활용해 부가 정보를 제공할 수 있다

3. 메서드 쪼개기

• 검사 예외를 회피하는 세 번째 방법은 검사 예외를 던지는 메서드를 2개로 쪼개어 비검사 예외로 바꾸는 것이다. 쪼개진 첫 번째 메서드는 예외가 던져질지 여부를 boolean값으로 반환한다.

try { obj.action(args);
} catch (TheCheckedException e) {
...// 예외 상황에 대처한다. 
}

if (obj.actionPermitted(args)) { 
    obj.action(args);
} else {
...// 예외 상황에 대처한다. 
}

• 이 리팩터 링을 모든 상황에 적용할 수는 없다. 그래도 적용할 수만 있다면 더 쓰 기 편한 API를 제공할 수 있다. 리팩터 링 후의 API가 딱히 더 아름답진 않지만, 더 유연한 것은 확실하다
• actionPermitted는 상태 검사 메서드에 해당하므로 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인에 의해 상태가 변할 수 있다면 이 리팩터링은 적절하지 않다

핵심 정리

꼭 필요한 곳에만 사용한다면 검사 예외는 프로그램의 안전성을 높여주지만，남용하면 쓰기 고통스러운 API를 낳는다. API호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자. 복구가 가능하고 호출자가 그 처리를 해주길 바란다면，우선 옵셔널을 반환해도 될지 고민하자. 옵셔널만으로는 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.