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

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

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

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

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

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

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

我认为当声明应用程序异常时，它应该是未检查的异常，即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或传播异常。在异常传播的情况下，由于异常处理，调用堆栈中的所有方法都将紧密耦合。这就是为什么我们必须小心地使用已检查异常。

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

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

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

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.