如何在架构级别计划例外情况?

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

未检查异常的一个例子是物理资源(如数据库或消息总线)不可用。在这种情况下,运行时异常是很好的,因为您不打算让资源不可用,所以您的业务逻辑不必经常检查databaseunavailableexception或类似的东西。您可以用不同的方式处理运行时异常(可能是aop发送电子邮件)来报告停机,并让员工或支持人员修复物理问题。

检查异常的例子可能是糟糕的数据输入,或不完整的数据访问,或一些实际上无法通过业务逻辑进行检查和恢复的东西。例如,您搜索的用户不可用。它是业务逻辑中的一个单独条件,可以检查和处理(例如,通过应用程序的视图部分,然后将异常的消息作为错误消息报告给用户)。

许多框架都使用这个模型,而且它似乎比我以前看到的更好。

也就是说,许多确实用返回的空值、-1、空字符串或number.min_值替换检查的异常。虽然这是可以的,但是如果您没有从数据源或方法中常规地期望这些值,那么可能应该将其表示为异常。

我通常发现过分关注检查异常是过分的。应为程序无法合理恢复的意外错误条件保留异常。对于这些,我倾向于同意你所观察到的,特殊的错误类型往往会失去它们的意义。

一般情况下,在以下所有条件均为真时引发异常:

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

您会发现,如果所有这些都是真的,那么异常的类型并不重要,您还可以抛出java.lang.error。如果其中任何一个是false,那么异常可能是过度终止(您真的需要类型、消息和堆栈跟踪吗?)

相反,可以考虑增加方法的返回类型,以指示预期的失败类型。例如,使用 Option<A> 在某些情况下不返回值可能有意义的方法的类型。使用一个 Either<A,B> 可能需要返回其类型取决于失败或成功的值的方法的类型。在以前可能有专门的异常子类型的情况下,您可以只使用<fail,a>其中fail只是预期失败类型的枚举。

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

在这种情况下,只要您给异常提供有意义的消息,并在必要时链接异常,就不能通过类识别异常并不是什么大损失。我经常抛出runtimeexception,而不是试图为每一个可能的错误案例开发一个异常类,但您对此的看法将取决于您在检查异常与未检查异常的争论中所处的位置。

"Effective Java," 2nd. ed. Bloch ,在第九章有一些好的建议。

"Hardcore Java," Simmons ,在第五章有一些好的建议。

我也会无耻地提到我写的 a small tool 管理Java异常源代码。异常代码通常是非常冗余的,您通常只关心类型。我的工具接受一个命名异常类型的配置文件,然后为这些异常生成代码。