如何使用c＃中的lambda表达式检测元素是否存在？

Question

我一直在使用try / catch语句来解析当我解析它时元素是否存在。 显然，这不是最好的方法。 我一直在使用LINQ（lambda表达式）进行大部分解析，但我只是不知道如何检测元素是否存在。

我发现的一些解决方案的一个大问题是它们使用的代码比使用try / catch块多3-4倍，这种方法无法实现。

我会假设代码看起来像这样：

if(document.Element("myElement").Exists())
{
   var myValue = document.Element("myElement").Value;
}

我确实找到了这个链接 ，但在我的情况下循环是不必要的，因为我可以保证它只会出现一次。 此外，必须创建一个似乎不必要的虚拟元素。 看起来不是检查的最佳方式（或好方法）。 有任何想法吗？

Answer 1

XElement e = document.Element("myElement");
if (e != null)
{
    var myValue = e.Value; 
}

http://msdn.microsoft.com/en-us/library/system.xml.linq.xcontainer.element.aspx

“获取具有指定XName的第一个（按文档顺序）子元素。”

“如果没有指定名称的元素，则返回Nothing。”

Answer 2

顺便说一句，上面关于“尝试/捕获”的评论可能是真的，但几乎并非在所有情况下。 这取决于您如何构建解决方案。 在你的Release版本中，尽可能多地关闭那些闻起来像“调试”的标志，即使是在远处也是如此。 在构建过程中，运行时被告知记住堆栈跟踪和填充物的次数越少，“try / catch”就越快。

顺便说一句，＃2：着名的建筑模式“告诉，不要问！” （TDA）和“公开关闭原则”（OCP） 禁止使用像“if（！（fp = fopen（...））”这样臭名昭着的代码。他们不仅鼓励你使用“try / catch” “但是强迫你这样做。因为OCP不仅要求在你自己的代码中服从，而且在调用外来东西时（例如stdio这样的库）。

为什么OCP，而不是最后一句中的TDA？ 因为您不允许扩大现有代码的含义。 坚持简单的“fopen”示例，当结果为零时你打算做什么？ 为什么“fopen”确实失败了？ 您可以检查是否有足够的空白空间，或者文件系统是否可写。 如果文件名有效。 或者诸如此类的。 但是，您的目标无法实现：打开文件。 想象一下无头应用程序，因此用户无法进行干预。 怎么办？ 没有理由进一步摸索这些东西，因为“fopen”失败了。 你需要一个后备策略。 点。 如果“fopen”失败，则失败。

经验法则：将您的代码视为始终成功（KIS）。 如果您的代码可能“失败”，结果集定期可能包含元素，请将逻辑放入类中。 也许您必须跨不同类（TDA）分发数据，属性，问题和方法。 也许您必须根据SLA重新调整代码。

但是，在您的情况下，请确保元素存在。 如果你做不到，那不是你的错。 在你的代码深处（一个包装器，前编码器的所有错误都被美化），将所需的数据转换为另一个实体，这样就不需要“if”了。

Answer 3

Any（）是Linq命令。

Assert.IsFalse( new [] { 1, 2, 3, 4 }.Any( i => i == 5 ));

Answer 4

Any()是检查元素是否存在的最简单方法。

如果必须确保元素是唯一的，则必须执行类似.Count() == 1 。 或者你可以实现自己的扩展方法，但这只是.Count == 1的包装器。