Unchecked Exception에 관한 논쟁

본문의 글은 오라클 문서를 번역한 글 입니다.

Unchecked Exceptions에 관한 논쟁

자바 프로그래밍 언어는 확인되지 않은 예외(RuntimeException, Error 및 그들의 하위 클래스)를 catch하거나 명시하는 것을 메소드에서 요구하지 않기 때문에, 프로그래머들은 UncheckedException만 던지도록 코드를 작성하거나 모든 예외 하위 클래스를 RuntimeException으로 상속하려는 유혹에 빠질 수 있습니다. 이러한 지름길을 사용하면 컴파일러 오류를 걱정하지 않고 예외를 지정하거나 잡지 않고 코드를 작성할 수 있지만, 이는 확인되지 않은 예외를 지정하거나 잡는 요구사항의 의도를 우회하며, 클래스를 사용하는 다른 사람들에게 문제를 일으킬 수 있습니다. 이는 프로그래머에게는 편리할 수 있지만, 기능적인 요구사항을 무시하는 것입니다.

 

왜 설계자들은 메소드가 범위 내에서 던질 수 있는 모든 CheckedException을 지정하도록 강제하기로 결정했을까요? 메소드에서 던질 수 있는 예외는 메소드의 공개 프로그래밍 인터페이스의 일부입니다. 메소드를 호출하는 사람들은 메소드가 던질 수 있는 예외를 알아야 하며, 그것들에 대해 어떻게 대처할지 결정할 수 있습니다. 이러한 예외는 메소드의 매개변수와 반환값과 마찬가지로 해당 메소드의 프로그래밍 인터페이스의 일부입니다.

 

다음 질문은 아마도 "메소드의 API를 문서화하는 것이 좋은 것이라면, RuntimeException도 지정하는 것이 왜 좋지 않을까요?"일 것입니다. RuntimeException은 프로그래밍 문제로 인한 문제를 나타내며, 따라서 API 클라이언트 코드가 이러한 예외를 복구하거나 처리할 수 있는 것은 합리적으로 기대할 수 없습니다. 이러한 문제는 0으로 나누기와 같은 산술 예외, null 참조로 객체에 액세스하려고 할 때 발생하는 포인터 예외 및 인덱스가 너무 크거나 작은 경우에 배열 요소에 액세스하려고 할 때 발생하는 인덱싱 예외를 포함합니다.

 

RuntimeException은 프로그램 어디에서나 발생할 수 있으며, 일반적으로 매우 많을 수 있습니다. 모든 메서드 선언에 RuntimeException를 추가해야하는 경우 프로그램의 가독성이 떨어질 수 있습니다. 따라서 컴파일러는 RuntimeException을 catch하거나 명시하도록 요구하지 않습니다(하지만 할 수는 있습니다).

 

RuntimeException을 던지는 일반적인 예는 사용자가 메서드를 잘못 호출하는 경우입니다. 예를 들어, 메서드는 인수 중 하나가 null인지 확인할 수 있습니다. 인수가 null이면, 해당 메서드는 NullPointerException을 던질 수 있으며, 이는 확인되지 않은 예외입니다.

일반적으로 메서드에서 던질 수 있는 예외를 지정하는 귀찮음 때문에 RuntimeException 또는 RuntimeException 하위 클래스를 만들지 마십시오.

 

한 줄 요약: 클라이언트가 예외에서 복구 할 수 있다면 CheckedException을 만들고 클라이언트가 예외에서 복구 할 수 없으면 UncheckedException을 만드십시오.