[아이템 70] 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라
상황에 맞게 예외를 사용하는 것이 이번 아이템의 주제이다.
자바의 문제 상황을 알리는 타입(thowable)
👉 검사 예외
👉 런타임 예외
👉 에러
자바의 예외 처리는 Throwable을 상속하고 있고 크게 Error와 Exception으로 나뉜다.
Error, RuntimeException은 비검사 예외이고, Exception은 검사 예외이다.
💡검사 예외 : 애플리케이션 수행 중 일어날법한 예외를 검사하고 대비하라는 목적으로 사용
💡비검사 예외 : 시스템적인 예외를 의미하고 개발자가 예외(try-catch)를 잡지 말라고 하며 심각한 상황에서 발생하는 예외
✅ "호출하는 쪽에서 복구하리라 여겨지는 상황이라는 검사 예외를 사용하라."
검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다.
검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.
= API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해 내라고 요구하는 것이다.
검사예외는 일반적으로 복구할 수 있는 조건일 때 발생하기 때문에 호출자가 예외 상황에서 벗어나는 데
필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다.
✅ "프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자."
비검사 예외는 런타임 예외와 에러가 있다.
이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다.
프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해 봐야 득보다는 실이 많다는 뜻이기 때문이다.
런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.
💡전제조건 위배 : 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 뜻
✅"에러는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다."
그래서 구현하는 비검사 예외는 모두 RuntimeException의 하위 클래스여야 한다.
Error는 상속하지도 말고, throw문도 던지지 말자
정리
복구가능 상황이면 검사 예외!프로그래밍 오류라면 비검사 예외를 던지자!확실하지 않다면 비검사 예외를 던지자!검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지도 말자
검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자