异常命名约定和 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将是更简洁的解决方案。