15

在工作中我将 String.IsNullOrEmpty 与 Session 变量一起误用后，我的一个同事现在拒绝接受我对 String.IsNullOrEmpty 的使用。经过一番研究，显然在 MSDN 上列出了 IsNullOrEmpty 的错误（链接）（阅读底部的注释）：

截至 2006 年 4 月 4 日，存在一个错误（可能在 JIT 中），当启用优化时，该错误会导致此方法失败。众所周知，它会影响 C# 和 VB。

更多信息可以在这里找到（链接）。微软这个错误“据说”是在 Orcas 之后修复的，但不幸的是我的雇主仍然使用 VS2005。但如果问题在 2008+ 年得到解决，那就这样吧。这对我来说很好。

虽然我的同事拒绝我的 IsNullOrEmpty 代码对我来说是盲目的无知 (IMO)，但他当然不能告诉我为什么不使用它，而不是滥用 session 变量。我在整个代码中都使用了 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 及更高版本一起使用？我意识到这对于这种愚蠢的小方法来说似乎有点矫枉过正，但我​​想知道幕后是否还有更多的事情发生，以及是否有人有其他解释。

4

10 回答 10

24

此问题已在 .NET 2.0 sp1 中修复。现在没有理由避免使用它。

如果您使用的是 .NET 2，那么出于许多其他原因，无论如何您都应该使用 sp1 - 我认为没有理由为不再存在的错误避免这种情况。

于 2009-11-06T22:40:46.160 回答
5

I've heard about that bug before, and from what I can gather it never occurs in any real code, only in code like the example that doesn't really do anything. Besides, the bug is not with the IsNullOrEmpty method itself, so it would occur regardless of how you check the string.

If the method does exactly what you want to do, you should use it. However, you should not use it in every situation to check for an empty string. Sometimes you only want to check if the string is empty and not if it's null.

If the string variable is null, this will just skip the code block:

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

If the string variable is null, this will cause an exception:

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

如果变量不应该为空，您可能需要异常而不是将空值视为空字符串的代码。如果出现问题，您希望尽早发现它，因为异常来自原因的时间越长，就越难将问题追溯到源头。

于 2009-11-06T22:47:05.630 回答
4

你可以编写一个传递空字符串的单元测试和传递一个空字符串的单元测试来测试这些东西，然后在 VS2005 和 2008 年之后运行它，看看发生了什么

于 2009-11-06T22:42:14.410 回答
3

在链接中的错误报告中，您包含它指出：

此错误已在 Microsoft .NET Framework 2.0 Service Pack 1 (SP1) 中得到修复。

既然是这种情况，只要您安装了用于 .NET 2 的 SP1，您是否使用 VS 2005 就无关紧要。

至于要不要用，看看CodingHorror 的这篇文章。

于 2009-11-06T22:42:44.100 回答
3

我们使用扩展方法string.IsNullOrEmpty：

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

使用这种方法，即使它在某些以前的版本中被破坏，一个错误修复也只是一行代码。

并且能够在可能为空的字符串实例上使用该方法的附加实用程序：

string myString = null;
if (myString.IsNullOrEmpty())
{
  // Still works
}
于 2009-11-06T22:47:00.523 回答
2

在 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");
}
于 2010-02-03T18:54:05.957 回答
1

我很确定它已在 SP1 上修复，但无论如何您都可以创建自己的 null 或空方法:)

于 2009-11-06T22:43:48.640 回答
1

与任何语言或其部分一样，这一切都是关于了解利弊并根据该信息做出有根据的决定。恕我直言。

于 2009-11-06T22:45:11.983 回答
0

如果它在您的版本中被破坏，那么只有一个静态方法来进行检查是微不足道的，所以只需执行以下操作：

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

就应该相对容易解决的问题陷入大问题是没有意义的。

您不需要在任何地方更改它，尽管您可以将一个静态方法全局替换为另一个。

于 2009-11-06T22:40:56.080 回答
-5

我想知道为什么人们使用 string.Empty，这不是一件好事，因为它是一个初始化的字符串，并且这个概念只存在于 .Net 框架中，任何地方这是一个 len 为 0 的有效字符串（数据库服务器在这之间做出了非常明确的区分，并且会抱怨如果您对 null 进行逻辑检查，但您得到的是空字符串）。我认为 string.IsNullOrEmpty 是我见过的前 5 个最糟糕的做法/功能之一，因为它以某种方式鼓励/使人们看起来可以初始化他们的字符串，并且可以被视为 null。这个函数不应该被添加，我认为.Net 的人应该尝试逐步淘汰它:) 无论如何谁需要和空字符串？我从来没有使用过它，除非我不得不因为现有项目使用它

于 2010-02-03T18:43:08.697 回答