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

10장. 예외 - GOAL

예외를 제대로 활용한다면 프로그램의 가독성, 신뢰성, 유지보수성이 높아진다.
그러나 잘못 사용하면 반대의 효과만 나타난다.
예외를 효과적으로 활용하는 방법을 습득하자.

아이템70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

자바에는 문제 상황을 알리는 타입으로 검사 예외, 런타임 예외, 에러, 이렇게 세가지를 제공한다.
하지만 언제 무엇을 사용해야 하는지 헷갈려 하는 프로그래머들이 종종 있다.

이럴 때 참고하면 좋은 지침들을 알아보자.

검사 예외 (Checked Exception)

• 호출하는 쪽에서 복구하리라 여기지는 상황
• 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다.
• 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.
• API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한 것이다.
  물론 사용자는 예외를 잡기만 하고, 별다른 조치를 취하지 않을 수도 있지만, 이는 보통 좋지 않는 생각이다.
• 검사 에외는 복구할 수 있는 조건에서 나타나므로, 상황을 벗어나는데 필요한 정보를 알려주는 메서드를 함께 제공해야 한다.
  • ex) 쇼핑몰에서 물건을 구입하려는 데 카드 잔고가 부족하여, 검사 예외가 발생했다. 그렇다면 이 예외는 잔고가 얼마나 부족한지 알려주는 접근자 메서드를 제공해야 한다.

비검사 예외 (Unchecked Exception)

프로그램에서 잡을 필요가 없거나, 혹은 통상적으로는 잡지 말아야 한다.
프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 잃을게 많다는 뜻이다.
이런 throwable(타입)을 잡지 않은 스레드는 적절한 오류 메시지를 내뱉으며 중단돈다.

런타임 예외 (Runtime Exception)

• 프로그래밍 오류를 나타낼 때 사용
• 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.
  • ex) 배열의 인덱스는 0 ~ '배열크기 - 1'. 지키지 못했을 때 : ArrayIndexOutOfBoundsExceptoin
  • 해당 오류는 프로그래밍 오류일수도 있고, 진짜로 자원이 부족해서 발생한 문제일 수도 있다.
• 복구 가능하다고 믿는다면 검사 예외를, 그렇지 않다면 런타임 예외를 사용하자. (결정하기 어려우면 비검사 예외!)

참고. 전제조건 위배 : 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 뜻

에러 (Error)

• 에러는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다.
• Error 클래스를 상속해 하위 클래스를 만드는 일은 자제해야한다.
• 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.
• Error는 상속하지 말아야할 뿐 아니라, throw 문을 직접 던지는 일도 없어야한다.(AssertionError는 예외)

결론

복구할 수 있는 상황 : 검사 예외 - 필요한 정보를 알려주는 메서드도 제공하자
프로그래밍 오류 : 비검사 예외
학실하지 않으면 : 비검사 예외
검사 예외도 아니고, 런타임 예외도 아닌 throwable은 정의하지도 말자.