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

Один из моих любимых методов в C++ был к DEBUG_ASSERT на Нулевых указателях. Это развернули в меня главные программисты (наряду с правильностью константы) и является одной из вещей, на которых я был самым строгим во время обзоров кода. Мы никогда не разыменовывали указатель без первого утверждения, что это не было пустым.

Отладка утверждает, только активно для целевых объектов отладки (она разделяется в выпуске), таким образом, у Вас нет дополнительных издержек в производстве для тестирования на тысячи if's. Обычно это или выдало бы исключение или инициировало бы аппаратную точку останова. У нас даже были системы, которые подбросят консоль отладки с информацией о файле/строке и опцией проигнорировать утверждение (однажды или неограниченно долго для сессии). Это было такой большой отладкой и инструментом QA (мы получим снимки экрана с утверждением на экране тестеров и информацией о ли программа, продолженная, если проигнорировано).

Я предлагаю утверждать все инварианты в Вашем коде включая неожиданные пустые указатели. Если производительность if's становится беспокойством, находят способ условно скомпилировать и сохранить их активными в целевых объектах отладки. Как управление исходным кодом, это - техника, которая сохраняла мою задницу чаще, чем это вызвало меня горе (самое важное решающее испытание какого-либо метода разработки).

Да, это - хорошая практика, чтобы проверить все аргументы в начале метода и выдать соответствующие исключения как ArgumentException, ArgumentNullException или ArgumentOutOfRangeException.

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

Если ПУСТОЙ УКАЗАТЕЛЬ является неприемлемым входом, выдайте исключение. Собой, как Вы сделал в Вашем образце, так, чтобы сообщение было полезно.

Другой метод обработки ПУСТЫХ исходных данных только к respont с ПУСТЫМ УКАЗАТЕЛЕМ в свою очередь. Зависит от типа функции - в примере выше я сохранил бы исключение.

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

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

Я добавлю несколько разработок (полужирным) к превосходному дизайну совета контракта, данного Brian ранее...

priniples "дизайна контракта" требуют, чтобы Вы определили то, что приемлемо, чтобы вызывающая сторона передала в (допустимый домен входных значений) и затем для любого допустимого входа, что сделает метод/поставщик.

Для внутреннего метода можно определить, АННУЛИРУЕТ как вне домена допустимых входных параметров. В этом случае Вы сразу утверждали бы, что входным значением параметра является NOT NULL. Ключевое понимание в этой спецификации контракта - то, что любая передача вызова в Нулевом значении ЯВЛЯЕТСЯ ОШИБКОЙ ВЫЗЫВАЮЩЕЙ СТОРОНЫ, и ошибка, брошенная оператором контроля, является правильным поведением.

Теперь, в то время как очень хорошо определено и экономный при представлении метода внешним/общедоступным вызывающим сторонам необходимо ли спросить себя, которые являются контрактом, который действительно хотят I/we?Наверное, нет. В открытом интерфейсе Вы, вероятно, приняли бы ПУСТОЙ УКАЗАТЕЛЬ (как технически в домене исходных данных, которые метод принимает), но затем откажитесь обрабатывать корректно w/сообщение возврата. (Больше работы для соответствия естественно более сложному стоящему с клиентом требованию.)

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

Необходимо проверить все аргументы по ряду допущений, что Вы делаете в той функции об их значениях.

Как в Вашем примере, если нулевой аргумент к Вашей функции не имеет никакого смысла и Вы предполагаете, что любой использующий Вашу функцию будет знать это, затем быть переданным нулевого аргумента показывает своего рода ошибку и своего рода принятые меры (например, выдача исключения). И если Вы используете, утверждает (как James Fassett, в которого входят и сказанный передо мной ;-)), они ничего не стоят Вам в версии выпуска. (они почти ничего не стоят Вам в отладочной версии ни один),

То же самое относится к любому другому предположению.

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

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

По словам Прагматически настроенного Программиста Andrew Hunt и David Thomas, это - обязанность вызывающей стороны удостовериться, что это дает допустимый вход. Так, необходимо теперь выбрать, полагаете ли Вы, что пустой вход допустим. Если не имеет определенный смысл полагать, что пустой указатель допустимый вход (например, это - вероятно, хорошая идея полагать, что пустой указатель легальный вход, если бы Вы тестируете на равенство), я считал бы это недопустимым. Тем путем Ваша программа, когда это поразит неправильный вход, перестанет работать раньше. Если Ваша программа собирается встретиться с состоянием ошибки, Вы хотите, чтобы она произошла как можно скорее. В конечном счете Ваша функция действительно непреднамеренно становится переданной пустой указатель, необходимо полагать, что это ошибка и реагирует соответственно (т.е. вместо того, чтобы выдать исключение, необходимо рассмотреть использование утверждения, которое закрывает программу, пока Вы не выпускаете программу).

Классический дизайн контракта: Если введенный будет правильным, то вывод будет правильным. Если введенный является неправильным, существует ошибка. (если введенный является правильным, но вывод является неправильным, существует ошибка. Это - дай мне.)

Большую часть времени разрешение ему просто выдать исключение довольно разумно, пока Вы уверены, что исключение не будет проигнорировано.

Если можно добавить что-то к нему, однако, не повреждает переносить исключение с тем, которое более точно, и повторно бросьте его. Декодирование "NullPointerException" собирается взять немного дольше, чем "IllegalArgumentException ("FilePath, ДОЛЖЕН быть предоставлен")", (Или безотносительно).

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

Я хотел бы видеть "nullable" или "nonull" модификатор на переменных и аргументах, таким образом, компилятор может проверить на Вас.

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

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

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