什么是自定义异常层次结构?

时间:2010-04-29 11:54:45

标签: exception

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

设计应用程序的体系结构, 从我的角度来看,我们可以有三种类型的例外:

  • 内置(例如:InvalidOperationException)
  • 自定义内部系统故障(提交时数据库事务失败,DbTransactionFailedException)
  • 自定义业务例外(BusinessRuleViolationException)

类层次结构:

  • 异常
    • MyAppInternalException
      • DbTransactionFailedException
      • MyServerTimeoutException
      • ...
    • MyAppBusinessRuleViolationException
      • UsernameAlreadyExistsException
      • ...

其中只有MyAppInternalException&将捕获MyAppBusinessRuleViolationException。

2 个答案:

答案 0 :(得分:4)

从类型F继承的异常类型E的真正好处显然是当E被一个模块捕获时,该模块并不是特别知道E是什么,但是确实知道F.假设继承有意义,模块有一个合理的希望对E异常采取正确的纠正措施,因为它是一种E异常。

所以我倾向于根据如何合理地处理异常来对异常进行分类。例如,典型的业务流程可能使用以下内容:

  • ConfigurationException - 可以通过更改配置文件来修复的事情。例如。 config无法解析或不一致。适当的响应是警告用户修复配置(如果可能,请提供有用的提示)。
  • InfrastructureException - 程序控制之外的资源可能偶尔会出错,例如远程服务器等。适当的响应通常是在暂停后断开连接并重试,如果有太多故障则放弃。
  • DataException - 传入数据中出错的内容。适当的响应是记录投诉(可能还有数据)并忽略此消息。

当然,这些可以是子类。但是,在该级别的区别对于更接近异常来源的模块通常更有用。如果异常一直到主模块,那么通常只有几个可能的操作,并且最容易在这些操作与它们响应的catch语句之间保持一对一的对应关系。

答案 1 :(得分:2)

“UsernameAlreadyExistsException”

我认为您不应该使用异常来控制应用程序的常规流程。即这是一个常规的商业案例,不应作为例外。在正确的应用程序设计中没有MyAppBusinessRuleViolationException。

此致