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

要问自己的问题:

1. 谁会抓住它?如果没有,那么您实际上不需要自定义异常。
3. 你为什么要扔它?因为您捕获了异常并需要附加附加信息?因为您在某些数据中遇到了不可恢复的错误,需要将具体信息反馈给客户端代码?因为你喜欢 throw 什么事?
4. 例外情况是什么?不是什么原因,而是什么原因 ? 他们可以修复并重试的东西?他们应该做的事 从不 什么 确定您需要传递的信息,如果有。。。

戒律:

1. 不要把时间浪费在永远不会被捕获的自定义异常上。
2. catch()
3. 好的

我是一个极简主义者,只有当调用代码必须显式地响应所发生的特定条件时,才会创建一个自定义异常。对于所有其他情况,我将使用最合适的.NET库异常。例如ArgumentNullException、InvalidOperationException

就这样,真的。当然,您也可以创建一个异常类,该类使用枚举来区分其原因。

当您希望传递额外信息时,这非常容易看到。传递该信息的唯一原因是您希望以后能够获取该信息,因此您希望知道该类型,以便可以从该类型而不是其他类型检索信息。

在C++中,也许还有其他语言,您也可能会有一个异常。这将允许区分类型,并可能在将来转换为自定义类。

像 Wheelie 也就是说,首先寻找合适的框架异常,并且只在您真正计划捕获它们的地方使用异常(特别是自定义异常)。

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

如果您使用的是.NET,请查看 Designing Custom Exceptions . 有趣的是,这些文档 changed its recommendation

如果您正在设计应用程序 这需要建立自己的机制 来自异常的自定义异常 班原来以为 自定义异常应派生自 然而,在实践中,这并没有得到证实 更多信息,请参阅最佳实践 用于处理异常。

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

我使用自定义异常的主要原因是使用多个提供程序进行封装:SqlDataAccess层中有一个SqlException泄漏,NetworkDataAccess层中有一个SocketException泄漏,这使得调用代码依赖于 实施最好将它们包装成DataAccessException或其他内容。

我还有一个第二条规则:“如果您希望开发人员能够处理异常,只创建一个自定义异常。”如果您不认为异常是可恢复的条件,那么创建新异常就没有意义。在该上下文中抛出InvalidOperationException更有效。

编辑:最后写了一篇关于这个主题的博文: http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx