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

我遇到了这个MSDN页面，其中指出：

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

不幸的是，它不会费心解释原因。我可以猜出原因，但我希望有人对此问题更有权威。

前两个很明显，但是后两个看起来就像您想雇用的（事实上，我有）。

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

Exception是所有异常的基本类型，因此非常不确定。您永远不要抛出此异常，因为它根本不包含任何有用的信息。调用代码捕获异常不会使故意抛出的异常（从您的逻辑）与其他完全不希望的系统异常，并指出真正的错误。

相同的原因也适用于SystemException。如果查看派生类型的列表，则可以看到大量其他语义非常不同的异常。

NullReferenceException并且IndexOutOfRangeException是另一种。现在这些都是非常特殊的例外，因此抛出它们可能很好。但是，您仍然不希望抛出这些错误，因为它们通常意味着您的逻辑中存在一些实际错误。例如，空引用异常意味着您正在尝试访问的对象的成员null。如果您的代码有这种可能，那么您应该始终显式检查null并抛出一个更有用的异常（例如ArgumentNullException）。同样，IndexOutOfRangeException当您访问无效索引（在数组上，而不是列表上）时，s会发生。您应该始终确保首先不要这样做，并首先检查例如数组的边界。

还有其他一些例外，例如InvalidCastException或DivideByZeroException，这两个例外是由于代码中的特定错误而抛出的，通常意味着您做错了什么，或者您没有先检查某些无效值。通过从代码中有意识地抛出它们，您使调用代码更难确定是由于代码中的某些错误而抛出它们，还是仅仅因为您决定将它们重用于实现中。

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

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

我怀疑最后两个的目的是防止与具有预期含义的内置异常混淆。但是，我认为，如果您保留例外的确切意图：它是的正确选择throw。例如，如果您正在编写一个自定义集合，则使用IndexOutOfRangeExceptionIMO 似乎比使用更加合理，更明确ArgumentOutOfRangeException。尽管List<T>可以选择后者，但BCL 中至少有 41个位置（由反射器提供）（不包括数组）可进行定制IndexOutOfRangeException-没有一个“低级别”足以值得特殊豁免。是的，我认为您可以公正地认为该准则很愚蠢。同样NullReferenceException 在扩展方法中很有用-如果您想保留以下语义：

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

抛出一个NullReferenceExceptionwhen obj是null。

如您所指出，在主题“ 抛出异常时应避免的事情”下的“ 创建和抛出异常”（C＃编程指南）中，Microsoft确实确实将异常类型列为不应从您自己的源代码中故意抛出的异常类型。System.IndexOutOfRangeException

相反，在本文（《 C＃参考》）中，Microsoft似乎违反了自己的准则。这是Microsoft包含在其示例中的方法：

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

因此，Microsoft本身并不一致，因为它证明了IndexOutOfRangeException其文档中有关throw！

这使我相信，至少对于的情况IndexOutOfRangeException，程序员有时可能会抛出该异常类型，并被认为是可以接受的做法。

当我阅读您的问题时，我问自己在什么条件下要抛出异常类型NullReferenceException，InvalidCastException或者ArgumentOutOfRangeException。

我认为，当遇到这些异常类型之一时，我（开发人员）会感到担心，因为编译器正在与我对话。因此，允许您（开发人员）抛出此类异常类型等同于（编译器）出售责任。例如，这表明编译器现在应允许开发人员确定对象是否为null。但是做出这样的决定实际上应该是编译器的工作。

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

把讨论关于NullReferenceException与IndexOutOfBoundsException旁白：

那接球和投掷呢System.Exception？我在代码中抛出了很多此类异常，但是我从来没有被它搞砸。同样，我经常遇到非特定Exception类型，它对我也很好用。那为什么呢？

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

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

编辑：也从MSDN页面：

在普通执行过程中，不应使用异常来更改程序的流程。异常应仅用于报告和处理错误情况。

对于不同的异常类型，使用具有单独逻辑的catch子句也不是最佳实践。