我們有多個啟用了可空參考型別的 .NET 6 專案。到目前為止，我們一直懶得為特定錯誤分配或創建例外型別。
目前我們代碼中最常用的 Exception 型別是 ArgumentException 和 ArgumentNullException。
后者的用例主要是：
在完整的屬性中：（我認為這些都很好）
public string OfferId
{
get => _offerId ?? throw new ArgumentNullException($"{nameof(ItemDTO)}.{nameof(OfferId)}");
set => _offerId = value;
}
在建構式中：（這些也有爭議）
NativeProductId = rawProduct.NativeProductId ??
throw new ArgumentNullException($"{nameof(rawProduct)}.{nameof(rawProduct.NativeProductId)}");
然后我們將它們用于任何遠程聞到null的東西，如果 HttpRequest 回傳空內容，如果 JsonConvert 回傳 null 等等，使用它們（這顯然很糟糕）
現在當我們想要重構時，很難理解在處理不同的錯誤時具體的例外應該是怎樣的。
（我在谷歌搜索時發現關于這個的資訊非常少）。
即自定義例外“DataNotFoundException”看起來非常廣泛，但可能可以描述這兩種情況（空內容和反序列化）。
另一方面，'ResposeContentNullException' 和 'JsonDeserializationNullException' 是非常具體的，但這意味著必須創建很多它們以涵蓋所有情況。
堆疊溢位的好人在創建、命名和使用例外時是否有任何規則或不成文的約定？
uj5u.com熱心網友回復：
例外可以看作是一種“特殊的回傳值”。它們是您的方法合同的一部分。如果您的方法已記錄在案，則該檔案應包括可以拋出的例外串列以及在哪些情況下會拋出它們（參見基類別庫中的此示例）。因此，在我看來，應該在設計/命名例外時考慮到方法的呼叫者。
換句話說，ResposeContentNullException并且JsonDeserializationNullException過于具體，因為它們包含有關您的方法的實作細節的資訊——您的方法的呼叫者不需要關心的細節。
相反，請檢查檔案并找出在哪些情況下回應內容可以為空：
如果發生通信故障時回應內容為空，則
IOException可能是合適的。如果回應內容永遠不能為空（根據檔案），則用戶在您的代碼和/或基類別庫中遇到了錯誤。在這種情況下，發出斷言失敗的例外信號將是最合適的。不幸的是，核心庫中沒有，所以我個人（ab）使用
InvalidOperationException它。一個 customLogicErrorException，AssertionFailedException或者ShouldNeverHappenException將是一個更清潔的解決方案。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/473234.html
上一篇：在C#中將所有例外發送到服務器