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

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

java.lang.SecurityException 

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

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

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

Из учебника Oracle Java :

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

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

Взгляните на 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.

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

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

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

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

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

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

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

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