你的自定义异常层次结构是什么？

Question

我的问题是：您将如何在应用程序中创建异常层次结构？

从我的角度来看，设计应用程序的架构时，我们可以有三种类型的异常：

1. 内置异常（例如：InvalidOperationException）； 2. 自定义内部系统故障（例如：数据库事务提交失败，DbTransactionFailedException）； 3. 自定义业务异常（例如：BusinessRuleViolationException）。

类层次结构如下：

- Exception - MyAppInternalException - DbTransactionFailedException - MyServerTimeoutException - ... - MyAppBusinessRuleViolationException - UsernameAlreadyExistsException - ...

只有 MyAppInternalException 和 MyAppBusinessRuleViolationException 会被捕获。

- Bonefisher

---

这是相当主观的，建议您编辑您的问题并勾选“社区维基”复选框（以免问题被关闭）。 - T.J. Crowder

Answer 1

继承类型F的异常类型E的真正好处显然在于当模块捕获一个不知道E是什么类型，但知道F的类型时。假设继承是有意义的，该模块有合理的希望根据E异常是一种E异常来采取正确的纠正措施。

因此，我倾向于根据异常可以合理处理的方式对其进行分类。例如，典型的业务流程可能使用以下内容：

ConfigurationException--可以通过更改配置文件来修复的问题。例如，配置无法解析或不一致。适当的响应是警告用户修复配置（如果可能，附带有帮助提示）。

InfrastructureException--与程序控制之外的资源（如远程服务器等）有关的间歇性错误。适当的响应通常是在暂停后断开连接并重试，如果失败次数太多，则放弃。

DataException--传入数据有误。适当的响应是记录投诉（可能还包括数据）并忽略此消息。

当然，这些可以被子类化。但是，在更靠近异常源头的模块中，区分通常更有用。如果异常一直冒泡到主模块，那么通常只有几个可能的操作，并且最好在这些操作和它们响应的catch语句之间建立一对一的对应关系。

- Edmund

Answer 2

"UsernameAlreadyExistsException"

我认为您不应该使用异常来控制应用程序的常规流程。也就是说，这是一个正常的业务情况，不应出现为异常。在正确的应用程序设计中，不存在MyAppBusinessRuleViolationException。

敬礼

- Alexis