Item71. 필요 없는 검사 예외 사용은 피하라

[Mingadinga]

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

검사 예외의 이점

검사 예외를 싫어하는 자바 프로그래머가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 검사 예외는 발생한 문제를 클라이언트가 직접 처리하도록 하여 안전성을 높이도록 해준다.

검사 예외의 단점

dsc-sookmyung/2023-Toby-Spring-Study#17

1. 검사 예외는 반드시 복구해야하므로, 과하게 사용하면 쓰기 불편한 API가 된다.
2. 검사 예외를 회피하기 위해 예외를 던지다보면 캡슐화를 깨뜨릴 수 있다.
3. 검사 예외를 던지는 메서드는 스트림 안에서 사용할 수 없다.

→ 결론 : API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우가 아니라면 비검사 예외를 사용하는 게 좋다!

(복구가 가능하다고 여겨지는 상황에서) 검사 예외의 대안

1. 적절한 결과 타입을 담은 옵셔널 반환하기
2. 상태 검사 메서드와 비검사 예외를 던지는 메서드 사용하기

// 1. 적절한 결과 타입을 담은 옵셔널 반환하기
// DB에 존재하지 않는 회원의 정보를 요청한 경우
return userRepository.findById(id).orElseThrow(
	new NotFoundException("요청한 회원이 존재하지 않습니다."));

// 2. 상태 검사 메서드와 비검사 예외를 던지는 메서드 사용하기

// 리팩터링 전 : 검사 예외를 던지는 메서드 
try {
	obj.action(args);
} catch (TheCheckedException e) {}

// 리팩터링 후 : 상태 검사 메서드와 비검사 예외를 던지는 메서드
if (obj.actionPermitted(args)) obj.action(args);
else ... 

리팩터링 후의 API가 딱히 더 아름답진 않지만, 더 유연한 것은 확실하다. 만약 프로그래머가 이 메서드 실패 시 스레드를 중단하기를 원한다면 그냥 obj.action(args);만 호출하면 된다. 한편 상태 검사 메서드를 사용할 경우, 다중 스레드에서 상태가 변경되어 의도하지 않은 결과가 발생할 수 있음을 주의해야한다.