Если я подавляю CA1062: Проверить аргументы открытых методов?
Я недавно обновил свой проект до Visual Studio 2010 из Visual Studio 2008.
В Visual Studio 2008 не существует это правило Анализа кода.
Теперь я не уверен, должен ли я использовать это правило или нет.
Я создаю библиотеку с открытым исходным кодом, таким образом, кажется важным охранять людей от выполнения ошибок. Однако, если все, что я собираюсь сделать, бросить ArgumentNullException когда параметр null, это походит на написание бесполезного кода с тех пор ArgumentNullException будет брошен, даже если я не напишу тот код.
Править: Кроме того, существует проблема производительности, которая должна быть решена. Проверка null в каждом открытом методе может вызвать проблемы производительности.
Я должен удалить то правило или зафиксировать нарушения?
3 ответа
Это зависит от обстоятельств. По соглашению при использовании ArgumentNullException в описание включается имя нулевого аргумента. Таким образом, вызывающий абонент будет точно знать, что пошло не так.
Источник исключения NullReferenceException (которое произойдет, если вы не выполните проверку) может быть легко обнаружить, но если метод сложен, это может быть труднее. Вы можете оказаться в строке кода, где несколько ссылок могут быть нулевыми.
Лично я предпочитаю, чтобы общедоступные методы генерировали исключение ArgumentNullException, если они не могут обрабатывать нулевой ввод для данного аргумента, потому что это обеспечивает согласованное поведение независимо от того, как реализован метод.
В ответ на редактирование: На мой взгляд, более важно предоставить последовательный набор интерфейсов с небольшим количеством сюрпризов, чем оптимизировать каждую строку кода. Я предполагаю, что в большинстве случаев накладные расходы на производительность нулевой проверки не будут значительными. Если это окажется проблемой (как сказано в профилировании), я бы подумал об изменении. В противном случае я бы сейчас не считал это проблемой.
IMHO Нет. Проверка на нули почти никогда не будет узким местом в производительности вашего приложения. (И в одном случае из миллиона, когда это важно, вы найдете его с помощью своего профилировщика и удалите этот случай).
Другой вопрос, который должен возникнуть у вас в голове: «действительно ли throw new NullReferenceException () лучший способ справиться с ошибкой?» Часто вы можете справиться с вещами лучше, чем это (даже если только чтобы предоставить лучший отчет об ошибках пользователю и / или себе для целей отладки). Во многих случаях код может изящно обрабатывать нули, что делает ненужным, чтобы это было ошибкой.
править
Чтобы ответить на ваше редактирование: Проверка на нулевое значение действительно не занимает много времени. Накладные расходы на простой вызов метода будут в десятки, если не в сотни раз больше, чем при нулевой проверке. Единственное место, где нулевая проверка будет иметь какое-либо существенное значение, - это большой, плотный цикл, в котором вы почти ничего не делаете. Такая ситуация случается не очень часто - обычно вы проверяете наличие null, а затем делаете что-то относительно дорогое с этой ссылкой.
Нет ситуации, когда авария или сбой - это хорошо. Всегда лучше «замедлить работу вашего приложения» с помощью нулевых проверок, чем потерпеть крах и потерять данные вашего клиента.
Так что не оптимизируйте код преждевременно. Напишите его хорошо, чтобы он был надежным и поддерживаемым, затем профилируйте , чтобы увидеть, где находятся узкие места. Я программировал 28 лет, очень либерально относился к нулевым проверкам, и никогда никогда не обнаруживал, что нулевая проверка была причиной проблем с производительностью. Обычно это такие вещи, как выполнение большого количества ненужной работы в цикле с использованием алгоритма O (n ^ 3), где возможен подход O (n ^ 2), невозможность кэширования дорогостоящих для вычисления значений и т. Д.
Мы сохраняем это правило, потому что мы решили, что всегда лучше проверять параметры при их первом входе в ваш код. Таким образом, когда человек, использующий ваш код, получит исключение, контекст в нем будет лучше. Например, кто-то, у кого нет вашего исходного кода, увидит, что в вашем коде возникло исключение, и может направить против вас отчет об ошибке за то, что оно напрасно тратит ваше и их время.