Java 如何在体系结构级别规划异常？

从架构的角度来规划如何使用异常，有什么好的资源吗？（或者直接在这里提供您的建议。）在我工作过的项目中，我发现一些常见的例外被反复使用，并且往往失去了它们的意义。 发件人：

，在第9章中有一些好的建议

，在第5章中有一些很好的建议

---

我还将无耻地提到，我编写了用于管理Java异常的源代码。异常代码通常是非常冗余的，您通常只关心类型。我的工具接受一个命名异常类型的配置文件，然后为这些异常生成代码。

我尝试确保使用try/finally的位置数量大大超过使用try/catch的位置数量。catch通常用于在顶层捕获异常，在顶层可以合理地处理异常，或者处理来自平台API的异常

---

在这种情况下，只要您为异常提供有意义的消息，并在必要时链接异常，无法通过其类识别异常并不是一个很大的损失。我经常抛出RuntimeException，而不是尝试为每一个可能出现的错误情况开发一个异常类，但您对此的看法将取决于您对检查异常与未检查异常的争论。我通常发现，过分关注检查异常是过火了。对于程序无法合理恢复的意外错误情况，应保留异常。对于这些，我倾向于同意你所观察到的，特殊的错误类型往往会失去它们的意义

作为一般规则，当以下所有条件均为真时引发异常：

• 这种情况在这里无法恢复
• 调用方无法合理地从这种情况中恢复
• 有人想调试这种情况，所以他们可能想查看堆栈跟踪

您会发现，如果所有这些都是真的，那么异常的类型并不重要，您还可以抛出java.lang.Error。如果其中任何一个为false，那么异常可能是过度杀戮（您真的需要类型、消息和堆栈跟踪吗？）

---

取而代之的是，考虑增加返回类型的方法来指示预期的故障类型。例如，对于某些情况下不返回值可能有意义的方法，请使用类型。对于可能需要返回其类型取决于失败或成功的值的方法，请使用类型。如果您以前可能有专门的异常子类型，您可以只使用其中任何一种，其中Fail只是预期失败类型的枚举。

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

如果物理资源（如数据库或消息总线）不可用，则会出现未经检查的异常。在这种情况下，RuntimeException很好，因为您不打算让资源不可用，所以您的业务逻辑不必经常检查DatabaseUnavailableException或类似的内容。您可以以不同的方式处理运行时异常（可能是AOP发送电子邮件），以报告停机情况，并让员工或支持人员解决物理问题

已检查异常的例子可能是糟糕的数据输入，或不完整的数据访问，或是某些实际上使业务逻辑失败，但可以检查并从中恢复的情况。例如，您搜索的用户不可用。它是业务逻辑中的一个单独条件，可以检查和处理（例如，由应用程序的视图部分进行检查和处理，然后将异常消息作为错误消息报告给用户）

许多框架都使用这个模型，而且它似乎比我以前看到的其他模型工作得更好

---

也就是说，许多情况下会用返回的null、-1、空字符串或Number.MIN_值替换已检查的异常。虽然这没关系，但如果您通常不希望从数据源或方法中获得这些值，则可能应该将其表示为异常。

是否要发布摘要？这听起来不像是架构级别的：-/抛出检查过的异常（糟糕的数据输入、不完整的数据访问、失败的业务逻辑）的原因不是异常情况，因此不需要异常。所以唯一“好”的异常是未检查的异常；无法恢复=未选中。是否捕获和处理它取决于调用方（或客户机代码），不应该由抛出的异常的检查性决定。大多数情况下，异常表示调用方无法恢复的情况。这就是为什么方法应该压制异常，并将它们作为特定异常重新引用的原因-如果调用方无法从IOException中恢复，则应该在内部捕获它，并引发另一个异常，说明操作失败，调用者可以从中恢复。对抛出错误的建议投了否决票，非基于sun的代码永远不应该抛出错误。然后，您将永远无法在标准异常顶级处理程序中捕获它，该处理程序应该捕获异常。抛出RuntimeException是一个好得多的主意，而且不会被检查，最好不要做任何事情来引起Java正统派警察的愤怒。错误自负。我不能保证你的安全。