Должны ли методы, которые генерируют RuntimeException, указывать это в сигнатуре метода?

Question

Например, многие методы в frameworks / JDK могут выдавать

java.lang.SecurityException 

но это не указано в сигнатуре метода (поскольку это практика, обычно зарезервированная для проверенных исключений) Я хочу утверждать, что объявление RuntimeExceptions в методах sigs имеет много преимуществ (например, статическая проверка типов). Я пьян или нет?

Answer 1

Я бы не объявил непроверенное исключение в подписи, поскольку оно вводит в заблуждение пользователя этого API. Больше не очевидно, должна ли быть явно обработана исключительная ситуация.

Объявление этого в javadoc - лучший подход, так как позволяет кому-то обращаться с ним, если он считает это необходимым, но зная, что может игнорировать его, если захочет. Это делает разделение между проверенным и непроверенным ясным.

Answer 2

С Обучающее руководство по Oracle Java :

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

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

Answer 3

Посмотрите на javadoc для Collection # add

Существует целый ряд упомянутых исключений:

Throws:
UnsupportedOperationException - add is not supported by this collection.
ClassCastException - class of the specified element prevents it from being added to this collection.
NullPointerException - if the specified element is null and this collection does not support null elements.
IllegalArgumentException - some aspect of this element prevents it from being added to this collection.

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

Answer 4

На мой взгляд, лучше объявить исключения во время выполнения хотя бы в javadoc для метода. Объявление этого в подписи делает еще более очевидным, что может случиться, если что-то пойдет не так. Это моя главная причина, по которой я предлагаю предоставить эту информацию.

К вашему сведению: со временем (сейчас в 2017 году) я сейчас гораздо больше склоняюсь к документированию их только в javadoc и максимально избегаю проверенных исключений.

Answer 5

Если вы пишете API для использования другими, то есть достаточная причина для явного документирования вашего намерения в API, и нет недостатка в объявлении RuntimeException в сигнатуре метода.

Answer 6

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

Если, однако, метод может генерировать некоторые непроверенные исключения, отмечая вероятные обстоятельства в @throws в Javadoc, это может быть полезно для других, вызывая метод для понимания того, что может пойти не так. Это полезно только для исключений, которые вызывающие абоненты могут обрабатывать (например, NPE из-за неправильного ввода и т. Д.)

Answer 7

Это связано с обсуждением проверенных исключений . Большинство согласится с тем, что исключения не должны объявляться в сигнатурах методов.

Существует также обсуждение относительно того, как следует использовать исключения во время выполнения. Я согласен с одним постером, что исключения во время выполнения должны обозначать программную ошибку или фатальное состояние. Таким образом, нет особого смысла декларировать их в подписи. Каждый метод может потенциально через один.