是否有足够的资源来计划从体系结构的角度计划如何使用异常？ (或者直接在此处提供建议。)在我从事过的项目中，我发现一再重复使用一些常见的异常，并且往往会失去其含义。
来自：http://jamesjava.blogspot.com/2007/10/exception-plan.html

解决方案

回答

"有效的Java"，第2版。 ed。 Bloch在第9章中提供了一些很好的建议。

回答

我试图确保使用try / final的位数大大超过使用try / catch的位数。通常，将catch保留用于在可以合理处理它们的顶层捕获异常，或者处理平台API中的异常。

在这种情况下，只要我们向异常提供有意义的消息，并在必要时提供链式异常，则无法通过其类识别异常并不是很大的损失。我经常抛出RuntimeException，而不是尝试为每个可能的错误案例开发一个异常类，但是我们对此的看法将取决于我们在检查与未检查的异常辩论中的位置。

回答

我通常发现，对检查的异常的痴迷是过大的。应该为程序无法合理恢复的意外错误情况保留异常。对于这些，我倾向于同意我们所观察到的观点，即特殊错误类型倾向于失去其含义。

通常，在满足以下所有条件时引发异常：

• 该条件无法从这里恢复。
• 不能合理预期呼叫者会从此状况中恢复。
• 有人会希望调试这种情况，因此他们可能想查看堆栈跟踪。

我们会发现，如果所有这些都是正确的，则异常的类型并不重要，并且我们最好抛出java.lang.Error。如果它们中的任何一个为假，则可能是一个过大的例外(我们真的需要类型，消息和堆栈跟踪吗？)

相反，请考虑增加方法的返回类型以指示预期的失败类型。例如，对某些情况下不返回任何值的方法使用Option <A>类型。对于可能需要返回其类型取决于失败或者成功的值的方法，请使用Either <A，B>类型。在以前可能具有专门的Exception子类型的地方，可以改用Either <Fail，A>，其中Fail只是对预期失败类型的枚举。

回答

我一半同意Apocalisp的评论。对于发生数据或者处理错误的情况，应保留Exception实例，但可以通过User或者System干预从中恢复。在应用程序范围内没有任何干预可以解决问题的情况下，应保留RuntimeException实例。因此，这两种类型称为Checked和Unchecked异常。

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

Checked异常的例子包括数据输入不当，数据访问不完整或者实际上使业务逻辑失败但可以从中进行检查和恢复的事情。例如，我们搜索的用户不可用。这是业务逻辑中的一个单独条件，可以检查和处理(例如，通过应用程序的"查看"部分，然后将"异常"消息作为错误消息报告给用户)。

许多框架都使用此模型，并且看起来比我以前看到的要好。

话虽这么说，但许多人确实用返回的null，-1，空String或者Number.MIN_VALUE代替了检查的异常。这样做可以，但是如果我们通常不希望从数据源或者方法中获得这些值，则应将其表示为异常。