如何在c＃中使用lambda表達式檢測元素是否存在？

我一直在使用try/catch語句來運行通過它時是否存在元素。顯然這不是做這件事的最好方法。我一直在使用LINQ（lambda表達式）進行大部分解析，但我不知道如何檢測元素是否存在。如何在c＃中使用lambda表達式檢測元素是否存在？

我發現的一些解決方案的一個大問題是，它們比使用try/catch塊多了3-4倍的代碼，這種方式無法達到目的。

我將承擔的代碼會是這個樣子：

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

我也覺得這link，但循環是在我的情況下不必要的，因爲我可以保證，它只會出現一次，如果它存在。另外還需要創建一個似乎不必要的虛擬元素。看起來這不是檢查的最佳方式（或一種好方法）。有任何想法嗎？

來源

2011-10-06 loyalpenguin

'try' /'catch'塊可能會非常慢。應該儘可能地避免它們。 – Enigmativity

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元件」。「

」如果沒有指定名稱的元素，則返回無。「

來源

2011-10-06 01:41:17

Any（）是Linq命令。

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

來源

2011-10-06 01:45:10

-1

Any()是檢查元素是否存在的最簡單方法。

如果您必須確保元素是唯一的，那麼您必須執行一些操作，如.Count() == 1。或者，你可以實現你自己的擴展方法，但這只是一個圍繞.Count == 1的包裝。

來源

2016-03-18 14:00:45 CarstenP

順便說一句，上面關於「try/catch」的評論可以是是真的，但幾乎不是所有情況。這取決於您如何構建解決方案。在您的發佈版本中，儘可能關閉儘可能多的標誌，即使遠處也有「調試」的味道。在構建過程中，運行時間被記憶爲堆棧軌跡和東西的時間越少，「try/catch」就越快。

順便說一句，＃2：着名的建築模式「告訴，不要問！」（TDA）和「Open Close Principle」（OCP）禁止使用這樣的臭名昭着的代碼，如「if（！（fp = fopen（...））」，他們不僅鼓勵你使用「try/catch「，但是強迫你這樣做，因爲OCP不僅要求遵守你自己的代碼，而且還要在調用外部東西（即stdio等庫）時使用OCP。你不能擴大現有代碼的含義，堅持簡單的「打開」的例子，當結果爲零時，你會怎麼做？爲什麼「打開」失敗？你可以檢查是否有足夠的空間或者文件系統是可寫的，如果文件名是有效的，或者不是，你的目標是無法實現的：打開文件，想象一下無頭應用程序，所以用戶不需要干預。那裏是沒有理由進一步摸索的東西，因爲「打開」失敗。你需要一個回退策略。點。如果「打開」失敗，則失敗。

經驗法則：認爲你的代碼總是成功（KIS）。如果你的代碼願意可能'失敗'的結果集定期可能包含元素或不，將邏輯放入類。也許你必須分佈不同類別（TDA）的數據，屬性，問題和方法。也許你必須根據SLA重新調整你的代碼。

儘管如此，請確保元素已存在。如果你不能，那不是你的錯。在代碼的深處（一個封裝器，前編碼器的所有錯誤都被美化了），將需要的數據轉換成另一個實體，這樣進一步就不需要「如果」。

來源

2017-05-07 11:53:13 CarstenP

返回null的代碼是後續代碼。檢查您自己的作用域中的值是否與違反TDA或OCP無關。 –

如何在c＃中使用lambda表達式檢測元素是否存在？

回答

相關問題