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

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

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

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

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

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

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

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

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

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

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

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

一个错误，一个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，抛出检查异常，无论如何都需要处理。对于其他情况，应用程序可以抛出未经检查的异常。如果应用程序调用方仍然需要处理未检查的异常，则可以这样做。

我们必须根据是否是程序员错误来区分这两种类型的异常。

If an error is a programmer error, it must be an Unchecked Exception. For example: SQLException/IOException/NullPointerException. These exceptions are programming errors. They should be handled by programmer. While in JDBC API, SQLException is Checked Exception, In Spring JDBCTemplate it is an Unchecked Exception.Programmer doesn't worry about SqlException, when use Spring. If an error is not a programmer error and the reason is coming from external, it must be a Checked Exception. For example: if the file is deleted or file permission is changed by someone else, It should be recovered.

FileNotFoundException是理解细微差别的好例子。在找不到文件的情况下抛出FileNotFoundException。这种例外有两个原因。如果文件路径是由开发人员定义的或通过GUI从最终用户获取的，那么它应该是一个未检查的异常。如果文件被其他人删除，它应该是一个Checked Exception。

检查异常可以用两种方式处理。它们使用try-catch或传播异常。在异常传播的情况下，由于异常处理，调用堆栈中的所有方法都将紧密耦合。这就是为什么我们必须小心地使用已检查异常。

如果您开发了一个分层的企业系统，您必须选择大多数未检查的异常来抛出，但不要忘记在您什么都做不了的情况下使用已检查的异常。