[Java] Unchecked Exception에 관한 논쟁

Java는 RuntimeException이나 Error와 같은 unchecked exception을 핸들링하도록 강제하지 않기 때문에, 프로그래머들은 unchecked exception만을 던지는 코드를 작성한다거나 RuntimeException을 상속하는 예외만을 만들어 사용하는 등의 유혹에 빠질 수 있다. 이렇게 하는게 프로그래머 입장에서는 편리할 지 모르지만, 이는 예외 처리에 관한 책임을 회피하는 것으로 이어져 결국 해당 클래스를 사용하는 쪽에서 문제가 발생하게 될 수 있다.

 

왜 Java를 설계한 사람들은 메소드 내부에서 발생할 수 있는 checked exception을 메소드에 명시하도록 강제했을까? 메소드를 호출하는 쪽에서는 해당 메소드가 어떤 예외를 발생시킬 수 있는지를 알아야 이를 어떻게 처리할지 결정할 수 있다. 이러한 예외 선언은 메소드 파라미터나 리턴 밸류와 마찬가지로 메소드 인터페이스로서의 기능을 한다.

 

위에서 말한 것 처럼, throw될 가능성이 있는 Exception을 메소드 선언부에 명시하는 것이 좋다면, 왜 runtime exception은 명시하도록 강제되지 않는가? Runtime exception은 프로그래밍의 문제로 인해 발생하는 예외를 의미하므로 메소드를 사용하는 측의 코드가 이러한 예외를 처리해주기를 기대하기란 어렵다.

Runtime exception은 프로그램 어느 곳에서나 발생할 수 있고, 그 수 또한 상당할 수 있다. 따라서 모든 메소드 선언에 runtime exception을 추가하게되면 가독성이 떨어질 수 있다. 그래서 컴파일러는 런타임 예외를 catch or throw할 것을 강제하지 않는다.

 

Runtime exception을 throw하게되는 일반적인 상황은 사용자가 메소드를 잘못 호출하는 경우이다. 예를 들어, 어떤 메소드 내에서 아규먼트가 null 값으로 잘못 들어오지 않았는지를 체크하는 경우가 있는데, 만약 아규먼트가 null인 경우에 해당 메소드는 unchecked exception 중 하나인 NullPointerException을 throw할 수 있다.

 

정리하면, 당신의 메소드가 어떤 예외를 발생시킬 지 명확히 하기가 귀찮다고 해서 무작정 RuntimeException을 던지거나, RuntimeException의 subclass를 만들어내지 말아라. 클라이언트 코드가 예외를 복구할 것으로 예상되는 경우에는 해당 예외를 checked exception으로 만들어라. 클라이언트 코드가 예외를 복구하기 어렵다고 판단되는 경우에만 이를 unchecked exception으로 만들어라.

 

 

---

 

Unchecked Exceptions — The Controversy (The Java™ Tutorials > Essential Java Classes > Exceptions)