Например, многие методы в рамках /JDK могут бросать
java.lang.SecurityException
но это не указывается в сигнатуре метода (поскольку это обычная практика, зарезервированная для отмеченных исключений). Я хочу утверждать, что объявление RuntimeExceptions в методах sigs имеет много преимуществ (например, для проверки статического типа). Я пьян или иначе?
Я не объявлял бы неконтролируемое исключение в подписи, так как оно вводит в заблуждение пользователя этого API. Уже не очевидно, должно ли явное обращение к исключению.
Объявление его в javadoc - лучший подход, поскольку он позволяет кому-то обрабатывать его, если они считают это необходимым, но зная, что они могут игнорировать его, если захотят. Это делает разделение между проверенными и непроверенными четкими.
"Если так хорошо документировать API-интерфейс метода, включая исключения он может бросить, почему бы не указать исключения времени выполнения тоже?" Runtime исключения представляют собой проблемы, являющиеся результатом программирования проблема, и как таковой, клиентский код 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 для метода. Объявление в подписи делает еще более очевидным, что может произойти, когда что-то пойдет не так. Это моя основная причина предлагать эту информацию.
FYI: по мере того, как время прогрессировало (теперь в 2017 году), я больше склоняюсь к документированию их только в javadoc и избегаю проверенных исключений как можно больше.
По моему мнению, исключенные исключения не должны быть объявлены в сигнатуре метода, поскольку это противоречит их природе.
Если, однако, метод, скорее всего, выкинет некоторые неконтролируемые исключения, отметив, что вероятные обстоятельства в @throws в Javadoc могут быть полезны для других, которые ссылаются на метод, понимая, что может пойти не так. Это полезно только для исключений, которые вызывающие могут обрабатывать (например, NPE из-за плохой записи и т.д.).
Если вы пишете api для использования другими, тогда есть достаточная причина для явной документации вашего намерения в api, и нет недостатка в объявлении RuntimeExceptions в сигнатуре метода.
Это связано с обсуждением проверенных исключений. Большинство согласится с тем, что исключения не должны быть объявлены в методах подписи.
Существует также обсуждение относительно использования исключений времени выполнения. Я согласен с одним плакатом, что исключения во время выполнения должны означать ошибку программирования или фатальное состояние. Таким образом, в подписи нет большого достоинства, объявляющего их. Каждый метод может потенциально через один.