[예외] p.290 3번쨰 문단 "...체크 예외를 사용하는 것이 적절하다."

[SeokRae]

반대로 애플리케이션 로직 상에서 예외조건이 발견되거나 예외상황이 발생할 수도 있다. 
이런 것은 API가 던지는 예외가 아니라 애플리케이션 코드에서 의도적으로 던지는 예외다. 
이때는 체크 예외를 사용하는 것이 적절하다. 
비즈니스적인 의미가 있는 예외는 이에 대한 적절한 대응이나 복구작업이 필요하기 때문이다.

이 문단의 내용은 unchecked exception에 대한 이야기를 하는거 아닌가요?

[SeokRae]

반대로 애플리케이션 로직 상에서 예외조건이 발견되거나 예외상황이 발생할 수도 있다. 
이런 것은 API가 던지는 예외가 아니라 애플리케이션 코드에서 의도적으로 던지는 예외다. 
이때는 체크 예외를 사용하는 것이 적절하다. 
비즈니스적인 의미가 있는 예외는 이에 대한 적절한 대응이나 복구작업이 필요하기 때문이다.

이 문단의 내용은 unchecked exception에 대한 이야기를 하는거 아닌가?

애플리케이션 로직 상에서 예외조건이 발견되거나 예외상황이 발생 한다는 의미를 비즈니스 로직상에서 발생할 수 있는 unchecked exception으로 이해했으나
하지만 API가 던지는 예외가 아니라 애플리케이션 코드에서 의도적으로 던지는 예외는 checked exception에 대한 내용을 말하는 것으로 이해하였습니다.

[SeokRae]

라고 했는데
p.292 두 번째 문단

API가 발생시키는 예외를 `체크 예외` 대신 `언체크 예외`로 정의 하는 것이 일반화되고 있다.
항상 복구할 수 있는 예외가 아니라면 일단 언체크 예외로 만드는 경향이 있다.
언체크 예외라도 필요하다면 얼마든지 catch 블록으로 잡아서 복구하거나 처리할 수 있다.
복구 불가능한 상황이고 보나마나 RuntimeException 등으로 포장해서 던져야 할테니 
아예 API 차원에서 `런타임 예외`를 던지도록 만드는 것이다.

라고 하고 있습니다.

정리해보면 프로그램에서 발생하는 예외를 복구하기 위해서 체크 예외를 사용하고
예외가 발생하는 것을 처리할 수 없다면 언체크 예외로 처리하도록 하는 것이 기본 전략이었으나

초기 설계의 목적과는 다르게 표준 스펙 또는 오픈소스 프레임워크에서는 언체크 예외로 대부분 처리 하도록 바뀌었다.
왜냐하면 언체크 예외라도 필요한 경우 catch 블록으로 잡아서 복구하거나 처리할 수 있고
대개는 복구 불가능한 상황이고 보나마나 RuntimeException 등으로 포장해서 던져야 할테니 아예 API 차원에서 런타임 예외를 던지도록 만든다.