이 글에서 Exception을 명시한다는건 한 메서드 내에서 catch되지 않는 발생 가능한 Throwable을 메서드 선언부에 명시한다는 의미로 사용되었다.

void name() throws BlahException

왜 자바에서 CheckedException을 명시/catch하도록 디자인 하였는가?

Unchecked Exception의 경우와 달리 CheckedException이 발생 가능한 메서드(혹은 스코프)는 강제적으로 그 Exception을 catch하거나 메서드 선언부에 명시하도록 설계되어있다 (그렇게 하지 않으면 컴파일이 안된다). 그 이유는 무엇일까?

오라클의 Java Tutorial에 따르면 이 질문에 대한 답은 아래와 같다.

throw될 수 있는 Exception은 모두 메서드의 public programming interface의 일부분이다. 따라서 이를 호출하는 쪽은 어떤 예외가 throw될 수 있는지 알아야 하며, 이에 따라 무엇을 할지 결정해야한다.
호출 시 발생 가능한 Exception에 대한 정보는 메서드의 리턴 값, 파라미터 정보 만큼이나 public programming interface의 많은 부분을 차지하고 있다.

왜 UncheckedException은 명시/catch를 강제하지 않는가?

UncheckedException은 대부분 프로그래밍 문제에서 나온다. 따라서 어떠한 방식으로 합리적으로 UncheckedException을 다루거나 복구하기를 기대할 수 없다.

예를 들면 이런 것이다.

• 0으로 나누기
• 너무 작거나 큰 index로 array접근
• null이 할당된 Object 변수의 메서드를 호출

이러한 RuntimeException들은 어디서든지 발생 가능하다. 경우의 수가 무수히 많아 이를 모두 명시한다면, 소스코드가 매우 난잡해 질 것이다. 따라서 컴파일러는 RuntimeException을 명시하거나 catch하도록 강제하지 않는다.

예시

대표적인 예시를 생각해봤을 때 Thread#sleep이 있다. Thread 클래스의 sleep 메서드는 InterruptedException을 throw한다고 명시하고있다(Checked Exception). 이 메서드는 Blocking 메서드다. 실행 과정에서 interruption이 발생할 수 있고, 이를 클라이언트 측(= Thread.sleep을 호출하는 코드 측)에서 복구 등의 대처를 하기를 합리적으로 기대해볼 수 있다.

Exception을 던질 때

API Client가 던져진 Exception에 대해
1. 회복이 가능하다면: CheckedException을 throw하자
2. 회복이 불가능하다면: UncheckedException을 throw하자

---

참고

• https://stackoverflow.com/questions/6115896/understanding-checked-vs-unchecked-exceptions-in-java
• https://stackoverflow.com/questions/36099102/what-does-mean-by-recoverable-and-un-recoverable-exception-or-error
• https://techblog.bozho.net/checked-and-unchecked-exceptions-in-java/
• https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html (설명이 꽤나 친절해서 이해하는데 큰 도움이 됐다.)