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

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

我同意将未检查异常作为规则的偏好，特别是在设计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，这是一个受检查的异常，最烦人的是——它应该是不受检查的，但开发人员根本没有考虑到这一点。

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

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

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

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

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

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

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

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.