以下是我的“最终经验法则”。 我使用:

方法代码中由于调用者导致的失败而出现的未检查的异常(这涉及一个显式和完整的文档) 检查异常失败由于被调用，我需要明确的任何人想要使用我的代码

与前面的答案相比，这是使用一种或另一种(或两种)例外的明确理由(人们可以同意或不同意)。

对于这两个异常，我将为我的应用程序创建自己的未检查和已检查的异常(这里提到过，这是一个很好的实践)，除了非常常见的未检查异常(如NullPointerException)

例如，下面这个特定函数的目标是创建(如果已经存在，则获取)一个对象， 意义:

the container of the object to make/get MUST exist (responsibility of the CALLER => unchecked exception, AND clear javadoc comment for this called function) the other parameters can not be null (choice of the coder to put that on the CALLER: the coder will not check for null parameter but the coder DOES DOCUMENT IT) the result CAN NOT BE NULL (responsibility and choice of the code of the callee, choice which will be of great interest for the caller => checked exception because every callers MUST take a decision if the object can not be created/found, and that decision must be enforced at the compilation time: they can not use this function without having to deal with this possibility, meaning with this checked exception).

例子:

/**
 * Build a folder. <br />
 * Folder located under a Parent Folder (either RootFolder or an existing Folder)
 * @param aFolderName name of folder
 * @param aPVob project vob containing folder (MUST NOT BE NULL)
 * @param aParent parent folder containing folder 
 *        (MUST NOT BE NULL, MUST BE IN THE SAME PVOB than aPvob)
 * @param aComment comment for folder (MUST NOT BE NULL)
 * @return a new folder or an existing one
 * @throws CCException if any problems occurs during folder creation
 * @throws AssertionFailedException if aParent is not in the same PVob
 * @throws NullPointerException if aPVob or aParent or aComment is null
 */
static public Folder makeOrGetFolder(final String aFoldername, final Folder aParent,
    final IPVob aPVob, final Comment aComment) throws CCException {
    Folder aFolderRes = null;
    if (aPVob.equals(aParent.getPVob() == false) { 
       // UNCHECKED EXCEPTION because the caller failed to live up
       // to the documented entry criteria for this function
       Assert.isLegal(false, "parent Folder must be in the same PVob than " + aPVob); }

    final String ctcmd = "mkfolder " + aComment.getCommentOption() + 
        " -in " + getPNameFromRepoObject(aParent) + " " + aPVob.getFullName(aFolderName);

    final Status st = getCleartool().executeCmd(ctcmd);

    if (st.status || StringUtils.strictContains(st.message,"already exists.")) {
        aFolderRes = Folder.getFolder(aFolderName, aPVob);
    }
    else {
        // CHECKED EXCEPTION because the callee failed to respect his contract
        throw new CCException.Error("Unable to make/get folder '" + aFolderName + "'");
    }
    return aFolderRes;
}

受控异常非常好，只要你知道什么时候应该使用它们。对于SQLException(有时对于IOException)， Java核心API无法遵循这些规则，这就是它们如此糟糕的原因。

受控异常应该用于可预测的、但无法预防的、可以合理恢复的错误。

未检查异常应该用于其他所有事情。

我来解释一下，因为大多数人都误解了这句话的意思。

Predictable but unpreventable: The caller did everything within their power to validate the input parameters, but some condition outside their control has caused the operation to fail. For example, you try reading a file but someone deletes it between the time you check if it exists and the time the read operation begins. By declaring a checked exception, you are telling the caller to anticipate this failure. Reasonable to recover from: There is no point telling callers to anticipate exceptions that they cannot recover from. If a user attempts to read from an non-existing file, the caller can prompt them for a new filename. On the other hand, if the method fails due to a programming bug (invalid method arguments or buggy method implementation) there is nothing the application can do to fix the problem in mid-execution. The best it can do is log the problem and wait for the developer to fix it at a later time.

除非您抛出的异常满足上述所有条件，否则它应该使用未检查异常。

Reevaluate at every level: Sometimes the method catching the checked exception isn't the right place to handle the error. In that case, consider what is reasonable for your own callers. If the exception is predictable, unpreventable and reasonable for them to recover from then you should throw a checked exception yourself. If not, you should wrap the exception in an unchecked exception. If you follow this rule you will find yourself converting checked exceptions to unchecked exceptions and vice versa depending on what layer you are in.

对于已检查和未检查的异常，使用正确的抽象级别。例如，具有两种不同实现(数据库和文件系统)的代码存储库应该通过抛出SQLException或IOException来避免暴露特定于实现的细节。相反，它应该将异常包装在一个跨越所有实现的抽象中(例如RepositoryException)。

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

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

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

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

规则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).

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

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

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

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

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

从使用您的库的开发人员或使用您的库/应用程序的最终用户的角度来看，遇到由于不应出现的异常而导致应用程序崩溃的情况真的很糟糕。指望包罗万象也不行。

通过这种方式，最终用户仍然可以看到错误消息，而不是应用程序完全消失。