在我使用Session变量滥用String.IsNullOrEmpty的工作事件之后,我的同事现在拒绝接受我对String.IsNullOrEmpty的使用。经过一些研究,显然在MSDN(link)上列出了IsNullOrEmpty的错误(请参见底部的注释):
截至2006年4月4日,有一个错误 (可能在JIT中)使这个 优化时方法失败 打开。众所周知,两者都有影响 C#和VB。
可在此处找到更多信息(link)。微软的这个bug在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 / etc中的错误修复已经到位(并且正常工作),不是否有任何理由在VS2005及更高版本中使用String.IsNullOrEmpty?我意识到这对于这样一个愚蠢的小方法看起来有点过分,但我想知道是否有更多的幕后工作以及是否有人有其他解释。
答案 0 :(得分:24)
此问题已在.NET 2.0 sp1中修复。现在没有理由避免使用它。
如果您使用的是.NET 2,那么您应该将sp1用于其他许多原因 - 我认为没有理由为不再存在的错误避免这种情况。
答案 1 :(得分:5)
之前我听说过这个bug,而且从我收集到的内容来看,它永远不会出现在任何真正的代码中,只会出现在代码中,而不是真正做任何事情的代码。此外,错误不在于IsNullOrEmpty方法本身,因此无论您如何检查字符串都会发生错误。
如果方法完全符合您的要求,您应该使用它。但是,您不应该在每种情况下使用它来检查空字符串。有时你只想检查字符串是否为空,如果它是空的则不是。
如果字符串变量为null,则只会跳过代码块:
if (!String.IsNullOrEmpty(str)) { ... }
如果字符串变量为null,则会导致异常:
if (str.Length > 0) { ... }
如果变量不应为null,则可能需要异常而不是将null值视为空字符串的代码。如果出现问题,你想尽早发现它,因为从原因开始,异常的时间越长,就越难跟踪问题。
答案 2 :(得分:4)
你可以编写一个传递空字符串的单元测试和一个传递空字符串来测试这些东西的单元测试,然后在VS2005中运行它,然后在2008年之后看看发生了什么
答案 3 :(得分:3)
在链接中的错误报告中,您将其包括在内:
此错误已在Microsoft .NET Framework 2.0 Service Pack 1(SP1)中修复。
既然如此,只要你安装了SP1 for .NET 2就可以使用VS 2005。
关于是否使用它,请查看此post by CodingHorror。
答案 4 :(得分:3)
我们使用string.IsNullOrEmpty
的扩展方法:
public static bool IsNullOrEmpty(this string target)
{
return string.IsNullOrEmpty(target);
}
使用这种方法,即使它在某些先前版本中被破坏,错误修正只是一行代码。
并且能够在可能为null的字符串实例上使用该方法的附加实用程序:
string myString = null;
if (myString.IsNullOrEmpty())
{
// Still works
}
答案 5 :(得分:1)
我很确定它已在SP1上修复,但无论如何你可以创建自己的null或空方法:)
答案 6 :(得分:1)
与任何语言或其中的一部分一样,所有这些都是为了了解利弊,并根据这些信息作出有根据的决定。 IMHO。
答案 7 :(得分:1)
在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");
}
答案 8 :(得分:0)
如果它在您的版本中被破坏,那么只需要一个静态方法来进行检查就是微不足道的,所以只需这样做:
public static bool isNull(String s) {
return s == null || s.trim().length == 0;
}
对于那些应该相对容易修复的问题,没有任何意义。
您无需在任何地方更改它,但您可以将一个静态方法替换为另一个静态方法。
答案 9 :(得分:-5)
我想知道为什么人们使用string.Empty,这不是一件好事,因为它是一个初始化的字符串&这个概念只存在于.Net框架中,这是一个len为0的有效字符串(db服务器在这之间做了非常明确的命运,如果你有逻辑检查null但是你得到并且空字符串,则会抱怨)。 我认为string.IsNullOrEmpty是我见过的前5个最糟糕的练习/功能之一,因为它鼓励/使人看起来很好用来初始化他们的字符串和 可以视为null。这个功能应该从未添加过,我认为.Net的人应该尝试逐步淘汰:)谁还需要空字符串呢?我从来没有使用它,除非我不得不因为现有的项目使用它