为什么我们不抛出这些异常？

Question

我遇到this MSDN page 说：

不要故意从您自己的源代码中抛出Exception、SystemException、NullReferenceException 或IndexOutOfRangeException。

不幸的是，它懒得解释原因。我可以猜到原因，但我希望在这个主题上更权威的人可以提供他们的见解。

前两个有一些明显的意义，但后两个似乎是你想要雇用的（事实上，我有）。

此外，这些是我们应该避免的唯一例外吗？如果还有其他的，它们是什么，为什么也应该避免它们？

Answer 1

抛开关于NullReferenceException 和IndexOutOfBoundsException 的讨论：

捕捉和投掷System.Exception。我在我的代码中经常抛出这种类型的异常，但我从来没有被它搞砸过。同样，我经常捕捉到不特定的Exception 类型，它对我来说也很有效。那么，这是为什么呢？

通常用户争辩说，他们应该能够区分错误原因。根据我的经验，只有极少数情况下您希望以不同的方式处理不同的异常类型。对于那些您希望用户以编程方式处理错误的情况，您应该抛出更具体的异常类型。对于其他情况，我不相信一般的最佳实践指南。

所以，关于投掷 Exception，我认为没有理由在所有情况下都禁止这样做。

编辑：也来自 MSDN 页面：

不应将异常用作普通执行的一部分来更改程序的流程。异常只能用于报告和处理错误情况。

针对不同异常类型的单独逻辑过度使用 catch 子句也不是最佳实践。

Answer 2

正如您所指出的，在主题 引发异常时要避免的事情 下的文章 Creating and Throwing Exceptions (C# Programmming Guide) 中，Microsoft 确实将 System.IndexOutOfRangeException 列为不应故意从您的自己的源代码。

然而，相比之下，在文章throw (C# Reference) 中，微软似乎违反了自己的指导方针。这是 Microsoft 在其示例中包含的一种方法：

static int GetNumber(int index)
{
    int[] nums = { 300, 600, 900 };
    if (index > nums.Length)
    {
        throw new IndexOutOfRangeException();
    }
    return nums[index];
}

因此，Microsoft 本身并不一致，因为它在 throw 的文档中演示了 IndexOutOfRangeException 的抛出！

这让我相信，至少对于 IndexOutOfRangeException 的情况，可能存在程序员抛出该异常类型 并被考虑的情况一种可接受的做法。

Answer 3

当我读到你的问题时，我问自己在什么情况下会抛出异常类型 NullReferenceException、InvalidCastException 或 ArgumentOutOfRangeException。

在我看来，当遇到其中一种异常类型时，我（开发人员）会担心编译器正在与我交谈的警告。所以，允许你（开发者）抛出这样的异常类型就等于（编译器）出卖了责任。例如，这表明编译器现在应该允许开发人员决定一个对象是否为null。但是做出这样的决定应该是编译器的工作。

PS：自 2003 年以来，我一直在开发自己的异常，因此我可以随心所欲地抛出它们。我认为这样做是一种最佳做法。

Answer 4

Exception 是所有异常的基本类型，因此非常不具体。你永远不应该抛出这个异常，因为它根本不包含任何有用的信息。调用异常代码捕获无法区分故意抛出的异常（来自您的逻辑）与其他完全不希望出现的系统异常并指出真正的错误。

同样的原因也适用于SystemException。如果您查看派生类型的列表，您会发现大量其他具有非常不同语义的异常。

NullReferenceException 和 IndexOutOfRangeException 是不同的类型。现在这些是非常具体的异常，所以抛出它们可能没问题。但是，您仍然不想抛出这些，因为它们通常意味着您的逻辑中存在一些实际错误。例如，空引用异常意味着您正在尝试访问对象的成员null。如果您的代码中有这种可能性，那么您应该始终显式检查 null 并抛出更有用的异常（例如 ArgumentNullException）。同样，IndexOutOfRangeExceptions 在您访问无效索引（在数组而非列表上）时发生。您应该始终确保您首先不这样做，并检查例如的边界。首先是一个数组。

还有一些与这两个类似的其他异常，例如 InvalidCastException 或 DivideByZeroException，它们是针对您的代码中的特定错误而引发的，通常意味着您做错了什么或者您没有检查某些无效值第一的。通过故意从代码中抛出它们，您只会让调用代码更难确定它们是由于代码中的某些错误而被抛出，还是仅仅因为您决定在实现中重用它们。

当然，这些规则也有一些例外（哈哈）。如果您正在构建可能导致与现有异常完全匹配的异常的东西，那么请随意使用它，尤其是当您尝试匹配某些内置行为时。只需确保您选择了一个非常具体的异常类型即可。

一般来说，除非您找到满足您需求的（特定）异常，否则您应该始终考虑为特定的预期异常创建自己的异常类型。尤其是在编写库代码时，这对于分离异常源非常有用。

Answer 5

我怀疑最后 2 个的目的是防止与具有预期含义的内置异常混淆。但是，我认为如果您要保留异常的确切意图：它是throw 的正确意图。例如，如果您正在编写自定义集合，使用IndexOutOfRangeException 似乎完全合理——IMO 比ArgumentOutOfRangeException 更清晰、更具体。虽然 List<T> 可能会选择后者，但在 BCL（不包括阵列）中有 至少 41 个位置（由反射器提供）抛出定制的 IndexOutOfRangeException - 其中没有一个是“低级别“足以值得特别豁免。所以，是的，我认为您可以公正地辩称该准则很愚蠢。同样，NullReferenceException 在扩展方法中有点用——如果你想保留以下语义：

obj.SomeMethod(); // this is actually an extension method

当obj 是null 时抛出NullReferenceException。