예외(Exceptions)
#58 복구 가능한 상황에는 checked 예외를 사용하자
Effective Java - 예외(Exception)
#58 복구 가능한 상황에는 checked 예외를 사용하고 런타임 예외는 프로그램 에러에 사용하자
#01 http://www.oracle.com/technetwork/java/effective-exceptions-092345.html자바에서는 checked 예외(exception), 런타임 예외, 에러(error) 세 종류의 던질 수 있는(throwable) 예외를 제공합니다.
런타임 예외와 에러를 합쳐서 unchecked 예외라고 합니다.
// choose one
throw new Exception();
throw new RuntimeException();
throw new Error();
이들은 언제, 어떻게 이용해야 하는지에 대해 알아보겠습니다.
메서드 호출자가 당연히 예외 복구를 할 수 있는 상황에서는 checked 예외를 사용하자
checked 예외는 이 예외와 연관된 상황이 발생할 수 있다고 API 사용자에게 알려주는 신호입니다.
다른 말로, API 사용자 입장에서 checked 예외를 만났다는 것은, 이 예외를 복구하라는 지시를 API 설계자로부터 받은 겁니다.
따라서 API 사용자는 checked 예외를 try-catch문을 통해 처리하거나, throw 키워드를 통해 다시 예외를 던져야 합니다.
unchecked 예외는 복구가 불가능하고 계속 실행해도 이로운 점이 없다는 상황이라는 것을 의미합니다.
따라서 일반적으로 try-catch문으로 처리할 필요 없고, 이 예외가 발생하면 적합한 에러 메시지가 출력되면서 현재 실행 중인 스레드가 중단됩니다.
런타임 예외를 사용해서 프로그래밍 에러를 나타내자
대부분의 런타임 예외는 클라이언트가 API 명세에 설정된 계약을 지키지 않은, 사전 조건 위반(precondition violation)을 나타냅니다.
예를 들면, 특정 컨테이너의 인덱스 값은 0부터 (컨테이너 크기 - 1) 사이이어야만 하는 계약 사항이 있습니다.
이를 위반하면 아래와 같이 RuntimeException을 상속받은 IndexOutOfBoundsException이 발생합니다.
#02 RuntimeExceptionError로부터 상속받는 서브 클래스는 만들지 않는 게 좋다
에러(Error)는 주로 JVM에서 사용하며, 자원 부족, 불변 규칙 위반, JVM이 실행될 수 없는 상황 등을 나타냅니다.
따라서 에러를 상속받은 서브 클래스를 만들지 않는 게 좋습니다.
개발자가 구현하는 모든 unchecked 예외는 RuntimeException의 서브 클래스이어야 합니다.
복구가 가능한 상황 : checked 예외
복구가 불가능한 상황 : Runtime 예외
복구가 가능한지 불분명한 상황 : checked 예외
