[이펙티브 자바] 아이템 70: 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

본문은 Effective Java를 읽고 간단하게 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다.

 

선결론

• 복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자
• 확실하지 않다면 비검사 예외를 던지자
• 검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지 말자
• 검사 예외라면 복구에 필요한 정보를 알려주는 메서들들 제공하자

 

 

예외에 대한 기본 원칙

• 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라
  • API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구할 수 있다
• 프로그래밍 오류를 나타낼 떄는 런타임 예외를 사용하라
  • 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다
• 확신하기 어렵다면 비검사 예외를 선택하는 편이 더 낫다(아이템 71)

 

 

기타 TIP

• 직접 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다
  • Error는 상속하지 말아야 할 뿐 아니라, throw문으로 직접 던지는 일도 없어야 한다(AssertionError는 예외다)
• Exception, RuntimeException, Error를 상속하지 않는 throwable을 만들지마라
• 검사 예외는 일반적으로 복구할 수 있는 조건일 때 발생하므로, 호출자가 예외 상황에서 벗어나는데 필요한 정보를 알려주는 메서드를 함께 제공하라