Исключения непроверенные — Противоречие

Поскольку язык программирования Java не требует, чтобы методы поймали или определили исключения непроверенные (RuntimeException, Error, и их подклассы), программисты могут испытать желание записать код, который выдает только исключения непроверенные или заставить все их подклассы исключения наследоваться от RuntimeException. Оба из этих ярлыков позволяют программистам писать код, не беспокоясь ошибками компилятора и не потрудившись определять или ловить любые исключения. Хотя это может казаться удобным для программиста, это обходит намерение catch или specify требование и может вызвать проблемы для других, использующих Ваши классы.

Почему разработчики решали вынудить метод определить все непойманные проверенные исключения, которые могут быть выданы в пределах его контекста? Любой Exception это может быть брошено методом, часть общедоступного интерфейса программирования метода. Те, кто вызывает метод, должны знать об исключениях, что метод может бросить так, чтобы они могли решить, что сделать о них. Эти исключения являются так частью интерфейса программирования того метода как его параметры и return значение.

Следующий вопрос мог бы быть: "Если настолько хорошо задокументировать API метода, включая исключения это может бросить, почему бы не определить исключения на этапе выполнения также?" Исключения на этапе выполнения представляют проблемы, которые являются результатом проблемы программирования, и как таковой, клиентский код API, как могут разумно ожидать, не восстановится от них или обработает их всегда. Такие проблемы включают арифметические исключения, такие как деление на нуль; исключения указателя, такие как попытка получить доступ к объекту через нулевую ссылку; и индексация исключений, таких как попытка получить доступ к элементу массива посредством индексирования, которое является слишком большим или слишком маленьким.

Исключения на этапе выполнения могут произойти где угодно в программе, и в типичном они могут быть очень многочисленными. Необходимость добавить исключения на этапе выполнения в каждом объявлении метода уменьшила бы ясность программы. Таким образом компилятор не требует, чтобы Вы поймали или определили исключения на этапе выполнения (хотя Вы можете).

Один случай, где это - обычная практика, чтобы бросить a RuntimeException то, когда пользователь вызывает метод неправильно. Например, метод может проверить, ли один из его параметров неправильно null. Если параметр null, метод мог бы бросить a NullPointerException, который является исключением непроверенным.

Вообще говоря, не бросайте a RuntimeException или создайте подкласс RuntimeException просто, потому что Вы не хотите быть обеспокоенными определением исключений, Ваши методы могут бросить.

Вот направляющая линия нижней строки: Если клиент, как могут разумно ожидать, восстановится с исключения, сделайте его проверенным исключением. Если клиент не может сделать ничего, чтобы восстановиться с исключения, сделайте его исключением непроверенным.