Должны методы, которые бросают RuntimeException, указывают на это в сигнатуре метода?
Нечто подобное должно сработать:
$a = ["w","c","d","e","g","h"];
$b = ["c","d","e"];
$c = ["c","e","d"];
function containsSequence($arr, $subArray){
$keys = array_keys($arr, $subArray[array_keys($subArray)[0]]);
foreach($keys as $k) {
if(array_slice($arr, $k, count($subArray)) == $subArray){
return true;
}
}
return false;
}
echo 'Contains sequence: '.(containsSequence($a,$b)?'yes:':'no');
echo 'Contains sequence: '.(containsSequence($a,$c)?'ues':'no');
6 ответов
Я бы не объявлял непроверенное исключение в сигнатуре, поскольку это вводит в заблуждение пользователя этого API. Больше не очевидно, должно ли исключение обрабатываться явным образом.
Объявление его в javadoc - лучший подход, поскольку он позволяет кому-то обрабатывать его, если он считает это необходимым, но зная, что они могут игнорировать его, если захотят. Это делает четкое разделение между отмеченным и непроверенным.
Взгляните на 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 в сигнатуре метода.
Это связано с обсуждением проверенных исключений . Большинство согласится с тем, что исключения не должны объявляться в сигнатурах методов.
Существует также обсуждение относительно того, как следует использовать исключения во время выполнения. Я согласен с одним постером, что исключения во время выполнения должны обозначать программную ошибку или фатальное состояние. Так что нет особого смысла декларировать их в подписи. Каждый метод может потенциально через один.