我同意将未检查异常作为规则的偏好，特别是在设计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.

这不仅仅是从异常中恢复的能力问题。在我看来，最重要的是调用者是否对捕获异常感兴趣。

如果您编写的库用于其他地方，或应用程序中的较低级别层，请询问自己调用者是否有兴趣捕获(了解)您的异常。如果他不是，那么使用一个未检查的异常，这样就不会给他带来不必要的负担。

这是许多框架使用的哲学。尤其是Spring和hibernate——它们精确地将已知的受控异常转换为未检查异常，因为Java中过度使用了受控异常。我能想到的一个例子是来自json.org的JSONException，这是一个受检查的异常，最烦人的是——它应该是不受检查的，但开发人员根本没有考虑到这一点。

顺便说一下，大多数情况下，调用者对异常的兴趣与从异常中恢复的能力直接相关，但情况并非总是如此。

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

我同意将未检查异常作为规则的偏好，特别是在设计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.

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

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

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