我使用的规则是:永远不要使用未经检查的异常!(或者当你看不到任何方法的时候)

从使用您的库的开发人员或使用您的库/应用程序的最终用户的角度来看，遇到由于不应出现的异常而导致应用程序崩溃的情况真的很糟糕。指望包罗万象也不行。

通过这种方式，最终用户仍然可以看到错误消息，而不是应用程序完全消失。

我认为我们可以从以下几个问题来考虑例外:

为什么会发生异常?当它发生时我们能做什么

一个错误，一个bug。如方法调用空对象。

String name = null;
... // some logics
System.out.print(name.length()); // name is still null here

这种异常应该在测试期间修复。否则，它会破坏生产，你会得到一个非常严重的bug，需要立即修复。这种异常不需要检查。

通过来自外部的输入，您不能控制或信任外部服务的输出。

String name = ExternalService.getName(); // return null
System.out.print(name.length());    // name is null here

在这里，如果您希望在名称为空时继续，则可能需要检查名称是否为空，否则，您可以让它单独运行，它将在这里停止并向调用者提供运行时异常。 这种异常不需要检查。

通过来自外部的运行时异常，您不能控制或信任外部服务。

在这里，如果您希望在发生异常时继续执行，则可能需要从ExternalService捕获所有异常，否则，您可以不去管它，它将在这里停止并向调用者提供运行时异常。

通过来自外部的受控异常，您不能控制或信任外部服务。

在这里，如果您希望在发生异常时继续执行，则可能需要从ExternalService捕获所有异常，否则，您可以不去管它，它将在这里停止并向调用者提供运行时异常。

在这种情况下，我们需要知道ExternalService中发生了什么样的异常吗?这取决于:

如果您可以处理某些类型的异常，则需要捕获它们并进行处理。对其他人来说，泡一下。 如果您需要记录或响应用户特定的异常，您可以捕获它们。对其他人来说，泡一下。

在任何一个足够大的系统上，有很多层，检查异常是无用的，因为无论如何，您需要一个架构级策略来处理异常将如何处理(使用故障屏障)。

使用受控异常，您的错误处理策略是微管理的，在任何大型系统上都无法承受。

大多数情况下，您不知道错误是否“可恢复”，因为您不知道API的调用者位于哪一层。

假设我创建了一个StringToInt API，用于将整数的字符串表示形式转换为Int。如果API是用“foo”字符串调用的，我必须抛出检查异常吗?它可以恢复吗?我不知道，因为在他的层中，我的StringToInt API的调用者可能已经验证了输入，如果抛出这个异常，它要么是一个错误，要么是一个数据损坏，它是不可恢复的这一层。

在这种情况下，API的调用者不想捕获异常。他只想让异常“冒出来”。如果我选择了一个受控异常，这个调用者将有大量无用的catch块，只能人为地重新抛出异常。

大多数时候，什么是可恢复的取决于API的调用者，而不是API的编写者。API不应该使用受控异常，因为只有未受控异常才允许选择捕获或忽略异常。

当不太可能出现异常时，即使在捕捉到异常之后，我们也可以继续，并且我们不能做任何事情来避免该异常，那么我们可以使用受控异常。

当我们想做一些有意义的事情时，当一个特定的异常发生时，当这个异常是预期的，但不是确定的，那么我们可以使用受控异常。

当异常在不同的层中导航时，我们不需要在每一层都捕获它，在这种情况下，我们可以使用运行时异常或包装异常作为未检查的异常。

运行时异常是在异常最有可能发生的情况下使用的，没有办法进一步进行，并且没有任何东西可以恢复。在这种情况下，我们可以对这种异常采取预防措施。EX: NUllPointerException, ArrayOutofBoundsException。这些更有可能发生。在这种情况下，我们可以在编码时采取预防措施来避免这种异常。否则，我们将不得不在每个地方都写入try catch块。

更一般的例外情况可以设置为Unchecked，不太一般的例外情况将被检查。

以下是我在多年开发经验后的一些看法:

Checked exception. This is a part of business use case or call flow, this is a part of application logic we expect or not expect. For example connection rejected, condition is not satisfied etc. We need to handle it and show corresponding message to user with instructions what happened and what to do next (try again later etc). I usually call it post-processing exception or "user" exception. Unchecked exception. This is a part of programming exception, some mistake in software code programming (bug, defect) and reflects a way how programmers must use API as per documentation. If an external lib/framework doc says it expects to get data in some range and non null, because NPE or IllegalArgumentException will be thrown, programmer should expect it and use API correctly as per documentation. Otherwise the exception will be thrown. I usually call it pre-processing exception or "validation" exception.

目标受众。现在让我们来谈谈目标受众或设计例外的人群(根据我的观点):

检查异常。目标受众是用户/客户。 未经检查的异常。目标受众是开发人员。换句话说，未检查异常仅是为开发人员设计的。

通过应用程序开发生命周期阶段。

受控异常被设计为在整个生产生命周期中存在，作为应用程序处理异常情况的正常和预期机制。 未检查异常被设计为只存在于应用程序开发/测试生命周期期间，所有这些异常都应该在这段时间内得到修复，并且当应用程序已经在生产环境中运行时不应该抛出。

框架通常使用未检查异常(例如Spring)的原因是框架不能确定应用程序的业务逻辑，这取决于开发人员捕捉并设计自己的逻辑。

受控异常非常好，只要你知道什么时候应该使用它们。对于SQLException(有时对于IOException)， Java核心API无法遵循这些规则，这就是它们如此糟糕的原因。

受控异常应该用于可预测的、但无法预防的、可以合理恢复的错误。

未检查异常应该用于其他所有事情。

我来解释一下，因为大多数人都误解了这句话的意思。

Predictable but unpreventable: The caller did everything within their power to validate the input parameters, but some condition outside their control has caused the operation to fail. For example, you try reading a file but someone deletes it between the time you check if it exists and the time the read operation begins. By declaring a checked exception, you are telling the caller to anticipate this failure. Reasonable to recover from: There is no point telling callers to anticipate exceptions that they cannot recover from. If a user attempts to read from an non-existing file, the caller can prompt them for a new filename. On the other hand, if the method fails due to a programming bug (invalid method arguments or buggy method implementation) there is nothing the application can do to fix the problem in mid-execution. The best it can do is log the problem and wait for the developer to fix it at a later time.

除非您抛出的异常满足上述所有条件，否则它应该使用未检查异常。

Reevaluate at every level: Sometimes the method catching the checked exception isn't the right place to handle the error. In that case, consider what is reasonable for your own callers. If the exception is predictable, unpreventable and reasonable for them to recover from then you should throw a checked exception yourself. If not, you should wrap the exception in an unchecked exception. If you follow this rule you will find yourself converting checked exceptions to unchecked exceptions and vice versa depending on what layer you are in.

对于已检查和未检查的异常，使用正确的抽象级别。例如，具有两种不同实现(数据库和文件系统)的代码存储库应该通过抛出SQLException或IOException来避免暴露特定于实现的细节。相反，它应该将异常包装在一个跨越所有实现的抽象中(例如RepositoryException)。