【发布时间】：2008-10-12 18:44:34
【问题描述】：
自定义异常类什么时候最有价值？
是否存在应该或不应该使用它们的情况？有什么好处？
相关问题：
【问题讨论】：
【发布时间】：2008-10-12 18:44:34
【问题描述】：
要问自己的问题：
- 谁会抓住它？如果没有，那么您真的不需要自定义异常。
- 你会把它扔到哪里？是否有足够的上下文可用，或者您是否需要在异常对最终捕获器有用之前捕获并重新抛出多次？
- 你为什么要扔它？因为你发现了一个异常并且需要附加额外的信息？因为您在某些数据中遇到了不可恢复的错误，并且需要将具体情况传达回客户端代码？因为你喜欢
throwing 东西？ - 有什么例外？不是什么原因造成的，而是从捕手的角度来看是什么？他们可以修复并重试吗？他们应该永远重试的东西？他们应该通知用户什么？他们应该附加上下文信息然后重新抛出的东西？ 什么决定了你需要传递的信息，如果有的话......
戒律：
- 不要将时间浪费在永远不会被捕获的自定义异常上。
- 不要“加倍”异常：每个自定义异常类型都应该有一个明确定义的情况，它可以而且应该被捕获；不匹配的异常应分解为它们自己的自定义类型（而不是强制捕获器将条件逻辑构建到单个
catch()子句中）。 - 除非您有好的理由不这样做，否则始终允许从先前捕获的异常中附加内部异常/数据。丢失上下文很少有帮助。
【讨论】：
我是一个极简主义者，只有在调用代码必须明确对发生的特定条件做出反应时才会创建自定义异常。对于所有其他情况，我将使用最合适的 .NET 库异常。例如。 ArgumentNullException, InvalidOperationException
【讨论】：
当您需要以某种方式将一个例外与其他例外区分开来时。就是这样，真的。当然，您也可以创建一个异常类，该类使用枚举来区分其原因。
当你想传递额外的信息时，这很容易看到。传递该信息的唯一原因是您希望以后能够获取该信息，因此您需要知道该类型，以便您可以从该类型而不是其他类型中检索信息。
在 C++ 中，也许还有其他一些语言，你也可以 typedef 一个异常。这将允许类型区分，并可能在未来转换为自定义类。
【讨论】：
正如Wheelie 所说，首先寻找适当的框架异常，并且只在您真正计划捕获它们的地方使用异常（尤其是自定义异常）。
我使用了一个包含 UserMessage 属性的自定义异常类，这样我可以在可能的情况下以简单的语言将问题传播给用户。
如果您使用的是 .NET，请查看Designing Custom Exceptions。有趣的是，文档中有changed its recommendation关于ApplicationException的使用：
如果您正在设计应用程序 需要创建自己的 例外，建议您导出 来自 Exception 的自定义异常 班级。原本以为 自定义异常应该来自 ApplicationException 类； 然而在实践中，这并没有 发现增加了显着的价值。为了 更多信息，请参阅最佳实践 用于处理异常。
【讨论】：
不久前我写了一篇关于when to throw different types of exceptions, and when to create new exception types 的博客文章。它不是那么长，但可能太长了，无法粘贴到这里，所以请原谅我只是链接。它应该涵盖您关于为什么存在不同异常类型以及如何知道是否需要创建自定义异常类型的问题。
【讨论】：
-
Greg，我阅读了您的博客文章，并认为您可以将最后一部分复制到此处的回复中。尽管大多数回复往往不超过一个段落，但没有什么能阻止你写更多：一些深入的回复可能比许多简短的回复更有效
我使用自定义异常的主要原因是封装了多个提供程序：SqlDataAccess 层外的 SqlException 泄漏，NetworkDataAccess 层外的 SocketException 使得调用代码取决于您的详细信息 执行。最好将它们包装成 DataAccessException 或其他东西。
【讨论】：
我认为简单的答案是“在没有现有异常充分表达异常情况时创建自定义异常。”
我还应用了第二条规则：“仅当您希望开发人员能够处理异常时才创建自定义异常。”如果您不认为异常是可恢复的条件，那么创建新异常是没有意义的。在这种情况下抛出 InvalidOperationException 更有效。
编辑：最后写了一篇关于这个主题的博客文章：http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx
【讨论】：