检查例外: 如果客户端可以从异常中恢复，并希望继续，请使用受控异常。

未经检查的异常: 如果客户端在异常发生后不能做任何事情，则引发未检查的异常。

示例:如果您希望在方法a()中执行算术操作，并且基于a()的输出，则必须执行另一个操作。如果方法A()的输出为空，而您在运行时并不期望它，那么您将抛出空指针异常，即运行时异常。

请参考这里

我同意将未检查异常作为规则的偏好，特别是在设计API时。调用方总是可以选择捕获记录在案的、未检查的异常。你只是没有必要强迫打电话的人。

I find checked exceptions useful at the lower-level, as implementation detail. It often seems like a better flow of control mechanism than having to manage a specified error "return code". It can sometimes help see the impact of an idea for a low level code change too... declare a checked exception downstream and see who would need to adjust. This last point doesn't apply if there are a lot of generic: catch(Exception e) or throws Exception which is usually not too well-thought out anyway.

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

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

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

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

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

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

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

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

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

我认为当声明应用程序异常时，它应该是未检查的异常，即RuntimeException的子类。 原因是它不会用try-catch和方法上的抛出声明使应用程序代码混乱。如果你的应用程序使用Java Api，抛出检查异常，无论如何都需要处理。对于其他情况，应用程序可以抛出未经检查的异常。如果应用程序调用方仍然需要处理未检查的异常，则可以这样做。