Вопрос

После инцидента на работе, когда я неправильно использовал String.IsNullOrEmpty с переменной сеанса, мой коллега теперь отказывается принять мое использование String.IsNullOrEmpty.После некоторых исследований выяснилось, что в MSDN указана ошибка для IsNullOrEmpty (связь) (читайте примечание внизу):

По состоянию на 4 апреля 2006 года есть ошибка (возможно, в JIT), которая делает этот метод сбоем при включении оптимизации.Известно, что он влияет как на C#, так и VB.

Более подробную информацию можно найти здесь (связь).Ошибка Microsoft «предположительно» исправлена ​​после Orcas, но, к сожалению, мой работодатель все еще использует VS2005.Но если проблема будет решена в 2008+, пусть будет так.Меня это вполне устраивает.

Хотя отказ моего коллеги от моего кода с IsNullOrEmpty для меня является слепым невежеством (IMO), он, конечно, не может сказать мне, почему нет использовать его, кроме неправильного использования переменной сеанса.Я использовал IsNullOrEmpty во всем нашем коде без каких-либо проблем.Лично я считаю, что это гораздо более читабельно, если не считать выполнения двух действий в одном операторе.

Погуглив мнения по этому поводу, я нашел сайты, которые придерживаются позиции «за» и «против».Вот некоторые сайты, на которых я читал об этом:

https://blog.rthand.com/post/2006/06/22/1063.aspx

http://www.omegacoder.com/?p=105

Один сайт(http://dotnetperls.com/isnullorempty) довольно хорошо резюмирует метод (ИМХО):

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

Предполагая, что исправление ошибки установлено (и работает правильно) в VS2008/2010/и т. д., есть ли какая-то причина? нет использовать String.IsNullOrEmpty с VS2005 и более поздними версиями?Я понимаю, что это может показаться излишним по сравнению с таким глупым методом, но мне хотелось бы знать, есть ли что-то еще за кулисами и есть ли у кого-нибудь альтернативные объяснения.

Это было полезно?

Решение

Эта проблема была исправлена ​​в .NET 2.0 SP1.Сейчас нет причин избегать его использования.

Если вы используете .NET 2, вам в любом случае следует иметь пакет обновления 1 по многим другим причинам — я не вижу причин избегать этого из-за ошибки, которой больше не существует.

Другие советы

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

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

Если строковая переменная имеет значение NULL, блок кода будет просто пропущен:

 if (!String.IsNullOrEmpty(str)) { ... }

Если строковая переменная равна нулю, это вызовет исключение:

 if (str.Length > 0) { ... }

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

вы можете написать модульный тест, который передает пустую строку, и тот, который передает нулевую строку, чтобы проверить это, и запустить его в VS2005 и позже в 2008 году и посмотреть, что произошло

В этом отчете об ошибке по ссылке, которую вы включаете, говорится:

Эта ошибка исправлена ​​в пакете обновления 1 (SP1) для Microsoft .NET Framework 2.0.

Поскольку это так, не имеет значения, используете ли вы VS 2005, если у вас установлен SP1 для .NET 2.

Что касается того, использовать его или нет, проверьте это сообщение от CodingHorror.

Мы используем метод расширения для string.IsNullOrEmpty:

public static bool IsNullOrEmpty(this string target)
{
  return string.IsNullOrEmpty(target);
}

Используя этот подход, даже если он был сломан в какой-то предыдущей версии, исправление ошибки — это всего лишь одна строка кода.

И добавленная утилита, позволяющая использовать этот метод для экземпляра строки, которая может иметь значение null:

string myString = null;
if (myString.IsNullOrEmpty())
{
  // Still works
}

Я почти уверен, что это было исправлено в SP1, но в любом случае вы можете создать свой собственный нулевой или пустой метод :)

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

При реализации проверки аргументов в API я обычно проверяю каждое условие отдельно и выдаю разные исключения: ArgumentNullException для нулевой ссылки или, в зависимости от спецификаций API, ArgumentException для пустой строки.В этом случае, используя String.IsNullOrEmpty не позволяет вам различать эти два отдельных состояния ошибки.

if (str == null)
{
    throw new ArgumentNullException("str");
}
if (str == string.Empty)
{
    throw new ArgumentException("The string cannot be empty.", "str");
}

Если в вашей версии он не работает, то просто иметь статический метод, который будет выполнять проверку, просто:

public static bool isNull(String s) {
  return s == null || s.trim().length == 0;
}

Нет смысла вступать в серьезную проблему из-за того, что относительно легко исправить.

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

Интересно, почему люди используют string.Empty, это нехорошо, потому что это инициализированная строка, и эта концепция существует только в фрейме .Net, везде это действительная строка с длиной 0 (серверы БД делают очень четкое различие между этим и будут жаловаться если у вас есть логическая проверка на ноль, но вы получаете пустую строку).Я думаю, что String.isnullorempty - одна из пяти лучших худших практик/функций, которые я когда -либо видел, потому что каким -то образом это поощряет/заставляет выглядеть нормально, чтобы инициировать свои строки и можно рассматривать как нулевые.Эту функцию никогда не следовало добавлять, и я думаю, что ребятам из .Net следует попытаться постепенно отказаться от нее :) Кому вообще нужна пустая строка?Я никогда не использовал его, если мне не приходилось, потому что существующие проекты использовали его.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top