Checked Exception vs Unchecked Exception

Exception과 Error

An exception is represented by an instance of the class Throwable (a direct subclass of Object) or one of its subclasses.
Throwable and all its subclasses are, collectively, the exception classes.
(subclass of Throwable must not be generic)
The classes Exception and Error are direct subclasses of Throwable.
Exception is the superclass of all the exceptions from which ordinary programs may wish to recover.
Error is the superclass of all the exceptions from which ordinary programs are not ordinarily expected to recover.
Error and all its subclasses are, collectively, the error classes.

 

공식 문서에 Exception과 Erorr를 위와 같이 정의하고있다.

Exception은 Throwable 클래스의 인스턴스거나 sub class(자식 클래스)이다.

Throwable이나 하위 클래스들은 모두 Exception 클래스라고 한다.

(여기서 하위 클래스들은 일반적인 클래스여서는 안된다고 나와있다.)

Exception 클래스나 Error 클래스는 Throwable 클래스의 자식 클래스로 정의되어있다.

 

Exception은 일반 프로그램이 복구할 수 있는 모든 예외(expcetion)들의 슈퍼 클래스(부모 클래스)이다.

Erorr는 일반 프로그램이 복구할 수 없는 에러(Error)에 대한 부모 클래스 라고 정의되어있다.

 

Exception과 Error는 모두 예외 상황이지만, 코드를 통해 복구시킬 수 있는 예외 상황이라고 생각하면 될 것 같다. (Error는 주로 JVM이 발생시키며, OutOfMemoryError, StackOverflowError 등이 그 예시)

 

Checked Exception과 Uncheck Exception

 

간단하게 차이점을 보면, RuntimeException을 상속했는가 아닌가의 차이로 구분지을 수 있다.

Checked Exception은 RuntimeException을 상속받지 않는 클래스이고, Unchecked Exceptoin은 RuntimeException을 상속받는 클래스다.

 

공식 문서에 따르면 RuntimeException은 Exception의 direct 자식 클래스라고 한다.

여러 표현식으로 부터 값을 표현하는 과정에서 모종의 이유로 예외를 발생시키는 모든 예외들의 부모 클래스이며, 여전히 회복이 가능한 상태인 Exception이라고 한다.

 

• Checked Exception

  • UnChecked Exception을 제외한 모든 Throwable 하위 클래스

  • Compile 시점에 확인되며 반드시 예외처리가 필요함 (try - catch, throws)

  • 예외가 발생해도 Rollback이 진행되지 않음

  • 기본적으로 복구가 가능하다는 메커니즘이 있어서, 직접 코드로 흐름을 제어해서 복구해줘야함.
    개발자가 복구할 수 있으니, Rollback을 진행하지 않는다는 의미

  • IOException, SQLException 등

• Unchecked Exception

  • RuntimeException 클래스와 Erorr 클래스

  • Runtime 시점에 확인되며 명시적으로 처리하지 않아도 됨

  • 예외 발생 시, Rollback이 진행됨

  • NullPointerException, ClassCastException 등

 

 

예외 처리

예외 처리에는 예외 복구, 예외 처리 회피, 예외 전환 방법이 있다.

• 예외 복구

  • 예외 상황을 파악하고 문제를 해결해서 정상 상태로 되돌리는 방법

  • 일정 시간이나 조건만큼 대기한 후 재시도

  • 최대 재시도 횟수를 넘기면 예외 발생

• 예외 처리 회피

  • 예외 처리를 호출한 쪽으로 던지는 방법

  • 어느 정도의 예외처리는 진행하고 던지는게 좋음

  • 역할을 분담하는 경우가 아니면 그냥 예외를 던지는 행위는 무책임함 (상위 컨텍스트의 책임이 증가)

• 예외 전환

  • 적절한 Exception으로 전환해서 예외를 던지는 방법

  • 조금 더 정확하고 명확하게 예외를 명시

  • 예외 처리를 단순하게 만들기 위해 Wrapping할 수 있음

 

예외 복구 전략이 명확하고 그것이 가능하다면 Checked Exception을 try catch로 잡고 복구를 하는 것이 좋다고 한다. 하지만, 흔지 않은 경우라서 Checked Exception이 발생하면 더 구체적인 Unchecked Exception을 발생시키고, 예외에 대한 메시지를 정확하게 전달하는 것이 효과적이라고 한다.

또한, 무조건 상위 메소드로 throws를 던지는 것은 좋지 않다. 그만큼 상위 메소드의 책임이 증가하기 때문이다. Checked Exception은 기본 트랜잭션 속성에서는 Rollback을 진행하지 않는다는 점을 기억해두자. (나중에 트랜잭션을 다뤄야하는 경우, 분명 필요함)

 

 

 

 

 

Red : UnChecked Exception, Blue : Checked Exception

 

Reference

 

docs.oracle.com/javase/specs/jls/se7/html/jls-11.html

cheese10yun.github.io/checked-exception/

madplay.github.io/post/java-checked-unchecked-exceptions

stackoverflow.com/questions/14771239/how-to-catch-all-checked-exceptions-in-a-single-block-in-java