Проверка аргументов функции?

Что Вы записали, предварительные условия и существенный элемент в Дизайне Контракта. Google (или "StackOverflow" :) для того термина и Вы найдете довольно большую хорошую информацию об этом и некоторую плохую информацию, также. Обратите внимание, что метод включает также постусловия и понятие инварианта класса.

Давайте оставим это ясным, что утверждения являются допустимым механизмом.

Конечно, они обычно (не всегда) не, зарегистрировался в режиме Release, таким образом, это означает, что необходимо протестировать код прежде, чем выпустить его.

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

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

Другие языки, как Java, имеют больше традиции явной проверки аргументов и выдавания исключения, если они неправы, главным образом потому что эти языки не имеют сильного, "утверждают", или "разрабатывают согласно контракту" традицию.

(Это может казаться странным для некоторых, но я нахожу различия в традиции значительными, и не обязательно злой.)

См. также этот связанный вопрос.

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

Любой код, который является вызываемым по сети или через, предает коммуникацию процесса земле, абсолютно должен иметь проверку параметра, потому что иначе это - уязвимость системы обеспечения безопасности - но необходимо бросить Отладку исключения. Утверждайте просто не сделает, потому что это только проверяет сборки отладки.

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

Отладка. Утверждайте в своей функции, должен только помочь ВАМ отладить, это - хороший первый оборонительный рубеж, но это не "реальная" проверка.

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

Для внутренних или закрытых функций, Отладки. Утверждайте прекрасен (но не необходим, IMO). Вы не будете брать в неизвестных параметрах, и Ваши тесты должны поймать любые недопустимые значения ожидаемым выводом. Но, иногда, Отладка. Утверждайте позволит Вам обнулить в на или предотвратить ошибку что намного более быстрый.

Для государственных функций, которые не являются вызовами API или внутренними методами, подвергающимися другим людям, называющим их, можно пойти так или иначе. Я обычно предпочитаю исключения для открытых методов и (обычно) позволяю внутренним методам обойтись без исключений. Если внутренний метод особенно подвержен неправильному употреблению, то исключение гарантировано.

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

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

public static void Function(int i, string s)
{
  if (i > 0 || !String.IsNullOrEmpty(s))
         Throw New ArgumentException("blah blah");
}

ПРЕДУПРЕЖДЕНИЕ: Это - воздушный кодекс, я, havn't протестировал его.

Необходимо использовать, Утверждают для проверки программных предположений; то есть, для ситуации, где

1. Вы - единственный, называя тот метод
2. это должно быть невозможное состояние для вхождения

Операторы контроля позволят Вам проверять это дважды, невозможное состояние никогда не достигается. Используйте это, где Вы иначе чувствовали бы себя комфортно без проверки.

Для ситуаций, где функции дают неверные аргументы, но Вы видите, что для него не невозможно получить те значения (например, когда кто-то еще мог назвать тот код), необходимо выдать исключения (а-ля @Nathan W и @Robert Paulson) или перестать работать корректно (а-ля @Srdjan Pejic).

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

public static void Function(int i, string s)
{
    if(i <= 0)
    {
        /*exit and warn calling code */
    }
}

Я нахожу, что это уменьшает объем пререкания, которое должно произойти.

Я не буду говорить с промышленными стандартами, но Вы могли объединиться, нижняя часть два утверждает в одну строку:

Debug.Assert(!String.IsNullOrEmpty(s));