異常命名約定和 scope

Question

我們有多個 .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”非常具體，但這意味着必須創建很多它們才能涵蓋所有情況。

stack-overflow 的好人在創建、命名和使用異常時是否有任何規則或不成文的約定？

Answer 1

異常可以看作是一種“特殊類型的返回值”。 它們是您的方法合同的一部分。 如果您的方法已記錄，該文檔應包括可以拋出的異常列表以及在何種情況下拋出異常（參見基礎 class 庫中的示例）。 因此，在我看來，在設計/命名異常時應考慮到方法的調用者。

換句話說， ResposeContentNullException和JsonDeserializationNullException過於具體，因為它們包含有關您的方法的實現細節的信息——您的方法的調用者不需要關心的細節。

而是查看文檔，找出什么情況下響應內容可以是null：

• 如果發生通信失敗時響應內容為null，則IOException可能是合適的。

• 如果響應內容永遠不會是 null（根據文檔），則用戶在您的代碼和/或基本 class 庫中遇到了錯誤。 在這種情況下，發出斷言失敗信號的異常將是最合適的。 不幸的是，核心庫中沒有，所以我個人（ab）為此使用InvalidOperationException 。 自定義LogicErrorException 、 AssertionFailedException或ShouldNeverHappenException將是更簡潔的解決方案。