자바 예외(Throwable)

---

■Throwable - 1depth

자바의 예외 계층의 최상위 클래스는 Throwable이다.

어떤 메서드가 Throwable을 throws하면 클라이언트는 무조건 throws된 Throwable에 대해

try-catch로 책임(?)을 지거나 다시 throws해서 자신의 클라이언트에게 책임을 떠넘겨야 

한다. 이런 에러 클래스를 검사 예외(checked exception)라고 지칭한다.

public class Test {
    public static void throwsToClient() throws Throwable{
        ExceptionClasses.throwsThrowable();
    }

    public static void catchImmediately() {
        try {
            ExceptionClasses.throwsThrowable();
        } catch (Throwable throwable) {
            throwable.printStackTrace();
            // do more process
        }
    }
}

class ExceptionClasses {
    static void throwsThrowable() throws Throwable {

    }
}

예제를 위해서 Throwable을 사용해봤는데, 일반적으로는 Throwable을 

이처럼 직접 사용하면 안된다. (상속 포함) 

그 이유는 Error 클래스 때문인데, 아래에서 설명하겠다.

---

■Error - 2depth

Throwable를 상속한 클래스이다. Error 클래스는 비검사 예외(unchecked exception)

클래스다. 다시말해, Error를 throws 하는 메서드를 사용하는 클라이언트는 Error에 대해 

별다른 조치를 취하지 않아도 된다.

public class Test {
    public static void errorExceptionTest() {
        ExceptionClasses.throwsError();
    }
}

class ExceptionClasses {
    static void throwsError() throws Error {

    }
}

Error는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 

나타낼 때 사용한다. 

개발자는 Error 클래스를 상속해 하위 에러 클래스를 만들면 안된다.

컴파일 레벨에서 못쓰도록 강제할 순 없지만 (자바 언어 명세가 요구하는 것은 아님) 

업계(?)에 널리 퍼진 약속이다. 에러 클래스를 만들고 싶다면 아래에 등장하는 

Exception이나 RuntimeException을 구현하자.

Error는 상속하지도 말고 위 예제처럼 throws나 throw로 직접 던지는 일도 없어야 한다!

---

■Exception - 2depth

Throwable를 상속한 클래스이다. Throwable와 같이 검사 예외 클래스다. 

사용법은 Throwable의 예제에 나온 것과 동일하다. 

Throwable와의 차이점은 catch의 매개변수로 사용하거나 throws(throw)의 타입으로 

사용할 때에 있다. catch의 매개변수 타입이나 throws(throw)의 타입을 

Throwable로 하면 Error 예외까지 처리할 수도 있다는 의미가 된다. 

개발자는 Error에 대해서는 코드상에서 신경써도 어찌할 방법이 없기 때문에(추측임) 

메서드를 사용하는 클라이언트에게 굳이 불필요한 오해를 줄 수 있는 것이다.

따라서 checked exception 클래스를 새로 만들고 싶다면 Throwable을 상속하지 말고 

Exception을 상속해야 한다.

---

■RuntimeException - 3depth

Exception을 상속한 클래스이다. Exception과는 달리 비검사 예외 클래스이다.

사용법은 Error의 예제에 나온 것과 동일하다. 

RuntimeException은 대부분 전제조건(클라이언트가 해당 API의 명세에 기록된 제약을 

지키지 못함)을 만족하지 못했을 때 발생한다. 예를 들어 배열의 인덱스가 0에서 

'배열 크기 -1' 사이를 벗어난 경우다. (ArrayIndexOutOfBoundsException)

unchecked exception 클래스를 새로 만들고 싶다면 Error를 상속하지 말고 

RuntimeException을 상속해야 한다.

(문득 든 생각인데, 예외 클래스들은 기본적으로 checked이고 특별한 경우(개발자가 

신경써도 한계가 분명한)에만 unchecked로 풀어두는 것 같다. checked나 unchecked는 

기술적으로 어떻게 설정하는건지 궁금해진다.)