java - 应该如何在架构层面规划异常？

Question

是否有任何好的资源可以从架构的角度规划如何使用异常？ (或者直接在这里提供你的建议。)在我工作的项目中，我发现一些常见的异常被反复使用并且往往会失去它们的意义。来自:http://jamesjava.blogspot.com/2007/10/exception-plan.html

Answer 1

我一半同意 Apocalisp 的评论。异常实例应保留用于发生数据或处理错误的情况，但可以通过用户或系统干预恢复。 RuntimeException 的实例应保留用于在您的应用程序范围内没有任何干预可以解决问题的情况。这两种类型因此被称为已检查异常和未检查异常。

未经检查的异常的一个示例是物理资源(例如数据库或消息总线)不可用。 RuntimeException 在这种情况下很好，因为您没有计划资源不可用，因此您的业务逻辑不必经常检查 DatabaseUnavailableException 或类似的东西。您可以以不同的方式处理 RuntimeExceptions(可能是 AOP 发送电子邮件)以报告中断并让工作人员或支持人员解决实际问题。

已检查异常的示例包括数据输入不当、数据访问不完整或实际上使业务逻辑失败但可以检查并从中恢复的情况。例如，您搜索的用户不可用。它是您的业务逻辑中的一个单独条件，可以检查和处理(比如通过您的应用程序的 View 部分，然后将异常消息作为错误消息报告给用户)。

许多框架都使用这个模型，它似乎比我以前见过的更好。

也就是说，许多确实用返回的空值、-1、空字符串或 Number.MIN_VALUE 替换了已检查的异常。虽然这没关系，但如果您不经常从数据源或方法中期望这些值，它可能应该表示为异常。