검사 예외 (Checked Exception)
호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외(checked exception)를 사용하라. checked exception은 호출자가 그 예외를 catch로 잡아 처리하거나, 위로 전파하도록 강제한다. 따라서 메서드 선언에 포함된 checked exception 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 클라이언트에게 알려주는 것이다.
unchecked throwable은 런타임 예외이거나 에러다. 이 둘은 프로그램에서 잡을 필요 없거나 혹은 통상적으로는 잡지 말아야 한다. 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다.
검사 예외는 일반적으로 복구할 수 있는 조건일 때 발생한다. 따라서 호출자가 예외 상황에서 벗어나는데 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다.
런타임 예외 (Unchecked Exception)
프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자. 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다. (ex. 배열 인덱스 크기. API 명세에 기록된 제약을 지키지 못했다는 것이다.)
물론 복구할 수 있는 상황인지 프로그래밍 오류인지 항상 명확히 구분되는 것은 아니다. 말도 안되는 크기의 배열을 할당해 생긴 프로그래밍 오류일 수도 있고 진짜로 자원이 부족해서 발생한 문제일 수도 있다.
에러
에러는 보통 더 이상 수행할 수 없는 상황을 나타낸다. 그래서 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다. Error는 상속하지도 말고, throw문도 던지지 말자 (AssertionError는 예외)
요약:
복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자. 확실하지 않다면 비검사 예외를 던지자. 검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지도 말자. 검사 예외는 복구에 필요한 정보를 제공하는 메서드도 제공하자.
궁금증
책에서는 복구할 수 있는 예외는 검사 예외를 사용하라고 했습니다. 저희 자동차 미션의 경우에 음수를 입력 받으면 예외를 반환하고, 호출한 곳에서 재귀를 통해 복구를 했습니다. 그러면 그때는 IllegalArgumentException이 아닌 검사 예외를 던지는게 맞았을까요?
저는 솔직히 말해서 해당 문항에 대한 이펙티브 자바의 설명이 이해되지 않고, 그래서 동의하지 않습니다. 전 토르가 작성하신 방식이 더 가독성있고 유지보수 하기 편하다고 생각해요.
- https://radio-weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
- https://www.artima.com/articles/the-trouble-with-checked-exceptions
최근에 생긴 언어들은Checked Exception이란 개념이 없는 언어가 더 많은 걸로 알고 있어요. 저도 역시나 checked exception이 필요한 개념일까 싶네요 -범블비-
