受控异常非常好，只要你知道什么时候应该使用它们。对于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)。

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

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

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

对于这两个异常，我将为我的应用程序创建自己的未检查和已检查的异常(这里提到过，这是一个很好的实践)，除了非常常见的未检查异常(如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;
}

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

受控异常非常好，只要你知道什么时候应该使用它们。对于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)。

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

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

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

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

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