我應該在自己的非LINQ代碼中使用DuplicateKeyException嗎？

Question

我正在爲一些業務關鍵型操作編寫審計服務。該服務正在使用IoC模式實施：因此，我需要它提出不特定於實現的異常。

審覈過程中的部分信息包括一個旨在唯一的密鑰。作爲該服務的當前要求，其作爲其審覈過程的一部分提供對關鍵唯一性的檢查。重複密鑰違反了流程要求。

目前，該服務將作爲寫入SQL-Server的方式來實現。儘管不太可能，但可能該密鑰可能是重複的，在這種情況下，會拋出SqlException抱怨主鍵約束違規。我寧願將這個異常封裝在一個更通用的「重複鍵」異常中，這個異常可以被捕獲，然後允許進程生成一個新的鍵。

通常，我討厭創建一個新的異常類;幾乎總是有一個合適的類型可用於傳達相同的信息。過去我已經抓到了System.Data.Linq.DuplicateKeyException，除了它來自LINQ相關的命名空間外，看起來像是一個很好的候選者，而且我的界面與LINQ沒有任何關係。

我急迫的選擇似乎是：

• 投擲System.Data.Linq.DuplicateKeyException無論如何，希望沒人看到的命名空間太多了。
• 丟棄System.InvalidOperationException並穿過我的手指我從來不需要一個可能因其他原因而拋出此異常的實現。
• 扔我自己的自定義DuplicateKeyException。
• 在接口中創建一個單獨的方法來檢查密鑰唯一性，並在寫入密鑰和值之前調用它。

你對此有什麼看法？

Answer 1

重新使用來自另一個命名空間異常 有時我會借存在於基本NET框架異常，但我覺得應該有行繪製。親自進入LINQ名稱空間只是爲了重新使用異常而跨越那條線，我不會這樣做。

使用InvalidOperationException 這是一個合理的使用，如果似乎不太可能需要專門捕獲異常的原因。這不是這種情況，所以我也不會那樣做。

使用自定義DuplicateKeyException 這是有道理的。這樣的例外可能是捕捉的候選對象，因爲它很可能代碼可能能夠做些什麼。異常來自你的名字空間，你可以添加其他相關的細節來幫助異常處理。

由於另一個線程改變事物添加「isUnique設置」方法 發生什麼情況，如果在調用「isUnique設置」和你的WriteAction方法的關鍵停止是唯一的之間，說什麼？這種方法可能是有用的，因爲沒有它，代碼可能依靠拋出異常來檢測它（這將是一件壞事）。然而，如果在WriteAction上關鍵的結果不是唯一的，你仍然需要創建一個異常，但不能保證接口的使用者甚至會首先調用「IsUnique」方法。