如果我需要从我的应用程序中抛出异常，我可以使用哪些内置.NET异常类？他们都是公平的游戏吗？我什么时候应该自己推出？
答案 0 :(得分：50)
请参阅Creating and Throwing Exceptions。
在抛出内置异常时，它说：
不要故意从您自己的源代码中抛出System.Exception，System.SystemException，System.NullReferenceException或System.IndexOutOfRangeException。
和
不要抛出一般例外
如果在库或框架中抛出一般异常类型（如Exception或SystemException），它会强制消费者捕获所有异常，包括他们不知道如何处理的未知异常。
相反，要么抛出一个已经存在于框架中的派生类型，要么创建自己的派生自Exception的类型。“
此blog entry也有一些有用的指导原则。
此外，FxCop代码分析将“不引发异常”列表定义为described here。它建议：
以下异常类型过于笼统，无法向用户提供足够的信息：
- System.Exception
- System.ApplicationException
- System.SystemException
以下异常类型是保留的，只能由公共语言运行库抛出：
- System.ExecutionEngineException
- System.IndexOutOfRangeException
- System.NullReferenceException
- 的System.OutOfMemoryException
所以从理论上讲，您可以引发任何其他框架异常类型，让您清楚地了解Microsoft所描述的异常意图（请参阅MSDN文档）。
请注意，这些是“指南”，正如其他人所说，围绕System.IndexOutOfRangeException存在争议（即许多开发人员抛出此异常）。
答案 1 :(得分：9)
关于System.Exception和System.ApplicationException的主题：后者旨在用作所有自定义异常的基类。但是，从一开始就没有一贯强制执行。因此，是否应该使用此类而不是使用System.Exception作为所有异常的基类存在争议。
无论你决定哪种方式，永远不会直接抛出这两个类的实例。遗憾的是，他们不是abstact。对于它的价值，总是尝试使用最具体的异常。如果没有人满足您的要求，请随意创建自己的要求。但是，在这种情况下，请确保您的例外优于现有例外。特别是，它应该完美地传达其含义，并提供以有意义的方式处理这种情况所需的所有信息。
避免创建不执行任何有意义的存根异常。同样，避免创建巨大的异常类层次结构，它们很少有用（尽管我可以想象一下我会使用它们的情况......解析器就是其中之一）。
答案 2 :(得分：6)
我经常使用ArgumentException（及其“朋友”）。
答案 3 :(得分：5)
我的建议是专注于两件事：
换句话说，我会坐下来确认：
＃1的答案当然是特定于应用程序的。 ＃2的答案是“他们已经熟悉过的类似代码”。
由此产生的行为是：
在您的程序中出现的情况下，也会到达 框架，例如参数为null，超出范围，无效，方法不是 正在实施，或者只是不受支持，那么你应该使用相同的例外 框架使用。使用您的API的人会期望他们的行为 方式（因为这是其他一切行为的方式），因此能够更好地使用 你的api来自“开始”。
一个。例外的主要目的是人类交流。他们传达 关于不应该发生的事情的信息。他们应该提供 足够的信息，以确定问题的原因，并弄清楚如何 解决它。
湾内部一致性非常重要。让您的应用程序表现得普遍 在类似情况下，尽可能使API的用户更有效率。
就你应该做什么和不该做什么有严格而快速的规则......我不会担心那些东西。相反，我只关注识别场景，找到适合这些场景的现有异常，然后在现有场景不存在的情况下仔细设计自己的场景。
答案 4 :(得分：1)
你可以创造和抛出任何一种，但你通常不应该。例如，各种参数验证异常（ArgumentException，ArgumentNullException，ArgumentOutOfRangeException等）适合在应用程序代码中使用，但AccessViolationException不适用。 ApplicationException作为您可能需要的任何自定义异常类的合适基类提供。
请参阅此MSDN article以获取最佳实践列表 - 它指的是处理异常，但也包含有关创建它们的好建议......