这里有一个非常简单的方法来解决你的“受控/未受控”困境。

规则1:将未检查异常视为代码执行前的可测试条件。 例如……

x.doSomething(); // the code throws a NullPointerException

其中x为空… 代码应该有以下内容

if (x==null)
{
    //do something below to make sure when x.doSomething() is executed, it won’t throw a NullPointerException.
    x = new X();
}
x.doSomething();

规则2:将检查异常视为代码执行时可能出现的不可测试条件。

Socket s = new Socket(“google.com”, 80);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();

在上面的例子中，URL (google.com)可能由于DNS服务器宕机而不可用。即使在DNS服务器工作并将“google.com”名称解析为IP地址的瞬间，如果连接到google.com，在任何时候，网络都可能瘫痪。你不能在读写流之前一直测试网络。

有时候，在我们知道是否存在问题之前，代码必须执行。通过强迫开发人员以这种方式编写代码，迫使他们通过检查异常来处理这些情况，我不得不向发明了这个概念的Java创造者致敬。

一般来说，几乎所有的Java api都遵循上述2条规则。如果尝试写入文件，磁盘可能会在完成写入之前被填满。可能是其他进程导致磁盘已满。根本没有办法测试这种情况。对于那些随时与硬件交互的人来说，使用硬件可能会失败，受控异常似乎是解决这个问题的一个优雅的解决方案。

这是一个灰色地带。在需要许多测试的情况下(一个带有大量&&和||的令人震惊的if语句)，抛出的异常将是一个CheckedException，因为要正确处理它太痛苦了——你不能简单地说这个问题是一个编程错误。如果测试少于10个(例如' If (x == null) ')，那么程序员错误应该是UncheckedException。

与语言口译员打交道时，事情变得有趣起来。根据上面的规则，语法错误应该被认为是一个检查或未检查的异常?我认为，如果语言的语法可以在执行之前进行测试，那么它应该是UncheckedException。如果无法测试该语言——类似于程序集代码在个人计算机上的运行方式，那么语法错误应该是一个已检查异常。

The 2 rules above will probably remove 90% of your concern over which to choose from. To summarize the rules, follow this pattern… 1) if the code to be execute can be tested before it’s executed for it to run correctly and if an Exception occurs — a.k.a. a programmer error, the Exception should be an UncheckedException (a subclass of RuntimeException). 2) if the code to be executed can not be tested before it’s executed for it to run correctly, the Exception should be a Checked Exception (a subclass of Exception).

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

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

一个错误，一个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中发生了什么样的异常吗?这取决于:

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

当你想要向调用者提供信息时，受控异常对于可恢复的情况很有用(例如，权限不足，文件未找到等)。

未检查异常很少用于在运行时通知用户或程序员严重错误或意外情况。如果你编写的代码或库将被其他人使用，不要抛出这些异常，因为他们可能不希望你的软件抛出未经检查的异常，因为编译器不会强制捕获或声明这些异常。

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

有一种情况正好相反:永远不要使用受控异常。我不愿意在辩论中偏袒任何一方(双方都有很好的论据!)，但相当多的专家认为，事后看来，受控例外是一个错误的决定。

对于一些讨论，请查看维基百科网站的“已检查异常的价值可疑”。另一个早期广泛争论的例子是Rod Waldhoff的博客文章。

You can call it a checked or unchecked exception; however, both types of exception can be caught by the programmer, so the best answer is: write all of your exceptions as unchecked and document them. That way the developer who uses your API can choose whether he or she wants to catch that exception and do something. Checked exceptions are a complete waste of everyone's time and it makes your code a shocking nightmare to look at. Proper unit testing will then bring up any exceptions that you may have to catch and do something with.

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

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)的原因是框架不能确定应用程序的业务逻辑，这取决于开发人员捕捉并设计自己的逻辑。