编写自定义异常类时应考虑哪些因素？

Question

自定义异常类何时最有价值？
是否应该或不应该使用它们？有什么好处？

相关问题：

1. 的 Performace Considerations for throwing Exceptions
2. 的 Do you write exceptions for specific issues or general exceptions?

Answer 1

问自己的问题：

1. 谁会抓住它？如果没有人，那么你真的不需要自定义异常。
2. 你要扔哪里？是否有足够的上下文可供使用，或者在异常对最终捕手有用之前是否需要多次捕获并重新抛出？
3. 你为什么扔它？因为您遇到了异常并需要附加其他信息？因为您在某些数据中遇到了不可恢复的错误，需要将详细信息传回客户端代码？因为你喜欢throw事物吗？
4. 什么是例外？不是什么造成了它，但从捕手的角度来看它是什么 ？他们可以修复并重试的东西？他们应该从不重试的东西？他们应该通知用户什么？他们应该将背景信息附加到然后再重新抛出？ 什么决定了您需要传递的信息，如果有的话......

训：

1. 不要在永远不会被捕获的自定义异常上浪费时间。
2. 不要“加倍”异常：每个自定义异常类型都应该有一个明确定义的案例，它可以并且应该被捕获;不匹配的异常应该分解为它们自己的自定义类型（而不是强迫catcher将条件逻辑构建为单个catch()子句）。
3. 除非您有良好的原因，否则始终允许从先前捕获的异常中附加内部异常/数据。失去上下文很少有用。

Answer 2

我有点极简主义，如果有调用代码必须明确地对发生的特定条件做出反应，那么它只会创建一个自定义异常。对于所有其他情况，我将使用最合适的.NET库异常。例如。 ArgumentNullException，InvalidOperationException

Answer 3

当你需要以某种方式区分一个例外时。就是这样，真的。当然，您也可以创建一个异常类，它使用枚举来区分其原因。

当您想要传递额外信息时，这很容易看到。传递该信息的唯一原因是，如果您希望以后能够获取该信息，那么您将需要知道该类型，以便您可以从该类型而不是其他类型中检索信息。

在C ++中，也许还有其他一些语言，你也可以输入一个例外。这将允许类型区分，并可能在将来转换为自定义类。

Answer 4

正如Wheelie所说，首先查看适当的框架异常，并且只使用异常（尤其是自定义异常），您真正计划捕获它们。

我使用包含UserMessage属性的自定义异常类，以便我可以在可能的情况下以简单语言将问题传播给用户。

如果您使用的是.NET，请查看Designing Custom Exceptions。有趣的是，文档对ApplicationException的使用有changed its recommendation：

  

如果您正在设计应用程序   需要创建自己的   例外情况，建议您派生   异常中的自定义异常   类。原本以为是这样的   自定义异常应来自   ApplicationException类;   但实际上并没有这样做   发现增加了重要的价值。对于   更多信息，请参阅最佳实践   处理例外。

Answer 5

我前段时间写了一篇关于when to throw different types of exceptions, and when to create new exception types的博客文章。这不是很长，但可能太长了，不能粘贴在这里，所以请原谅我只是链接。它应该包含您关于为什么存在不同异常类型的问题，以及如何知道是否需要创建自定义异常类型。

Answer 6

我使用自定义异常的主要原因是使用多个提供程序进行封装：从SqlDataAccess层泄漏SqlException，并且NetworkDataAccess层中的SocketException使得调用代码依赖于您的详细信息 实现。最好将它们包装成DataAccessException或其他东西。

Answer 7

我认为简单的答案是“当没有现有的异常表达特殊情况时，创建一个自定义异常。”

我还应用了第二条规则：“如果您希望开发人员能够处理异常，则只创建自定义异常。”如果您不将异常视为可恢复条件，则无法创建新异常。在该上下文中抛出InvalidOperationException更有效。

编辑：结束撰写关于此主题的博客文章：http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx