我认为受控异常对于使用外部库的开发人员是一个很好的提醒，在异常情况下，该库中的代码可能会出错。

关于未检查异常和已检查异常之间的区别，我最喜欢的描述来自Java教程的试用文章“未检查异常-争议”(很抱歉在这篇文章中介绍了所有基本的内容-但是，嘿，基本的有时是最好的):

这是底线原则:如果客户可以合理地 希望从异常中恢复，使其成为受控异常。如果 客户端不能做任何事情来从异常中恢复 未经检查的异常

“抛出哪种类型的异常”的核心是语义的(在某种程度上)，上面的引用提供了一个很好的指导方针(因此，我仍然被c#摆脱受控异常的概念所震撼——特别是Liskov认为它们有用)。

接下来的问题就变得合乎逻辑了:编译器希望我显式地响应哪些异常?你希望客户能从中恢复过来。

所有这些都是受控异常。未检查的异常是RuntimeException的子类。问题不在于如何处理它们，而在于你的代码是否应该抛出它们。如果你不想让编译器告诉你你还没有处理一个异常，那么你可以使用一个未检查的(RuntimeException的子类)异常。这些应该保存在你无法恢复的情况下，比如内存不足等。

我只是想添加一些根本不使用受控异常的理由。这不是一个完整的答案，但我觉得它确实回答了你的部分问题，并补充了许多其他的答案。

Whenever checked exceptions are involved, there's a throws CheckedException somewhere in a method signature (CheckedException could be any checked exception). A signature does NOT throw an Exception, throwing Exceptions is an aspect of implementation. Interfaces, method signatures, parent classes, all these things should NOT depend on their implementations. The usage of checked Exceptions here (actually the fact that you have to declare the throws in the method signature) is binding your higher-level interfaces with your implementations of these interfaces.

让我给你们看一个例子。

让我们有一个像这样漂亮干净的界面

public interface IFoo {
    public void foo();
}

现在我们可以编写方法foo()的许多实现，就像这样

public class Foo implements IFoo {
    @Override
    public void foo() {
        System.out.println("I don't throw and exception");
    }
}

类Foo完全没问题。现在让我们第一次尝试Bar类

public class Bar implements IFoo {
    @Override
    public void foo() {
        //I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
        throw new InterruptedException();
    }
}

这个类Bar不能编译。由于InterruptedException是一个已检查异常，您必须捕获它(在方法foo()中使用try-catch)或声明您正在抛出它(在方法签名中添加抛出InterruptedException)。因为我不想在这里捕获这个异常(我希望它向上传播，这样我就可以在其他地方正确地处理它)，让我们改变签名。

public class Bar implements IFoo {
    @Override
    public void foo() throws InterruptedException {
        throw new InterruptedException();
    }
}

这个类Bar也不能编译!Bar的方法foo()不会覆盖IFoo的方法foo()，因为它们的签名不同。我可以删除@Override注释，但我想编程接口IFoo像IFoo foo;然后再决定使用哪个实现，比如foo = new Bar();如果Bar的方法foo()没有覆盖IFoo的方法foo，当我执行foo.foo();它不会调用Bar的foo()实现。

To make Bar's public void foo() throws InterruptedException override IFoo's public void foo() I MUST add throws InterruptedException to IFoo's method signature. This, however, will cause problems with my Foo class, since it's foo() method's signature differs from IFoo's method signature. Furthermore, if I added throws InterruptedException to Foo's method foo() I would get another error stating that Foo's method foo() declares that it throws an InterruptedException yet it never throws an InterruptedException.

正如您所看到的(如果我在解释这些东西方面做得不错的话)，抛出InterruptedException这样的检查异常的事实迫使我将我的接口IFoo绑定到它的一个实现上，这反过来又会对IFoo的其他实现造成严重破坏!

这就是受控异常很糟糕的一个重要原因。在帽。

一种解决方案是捕获已检查异常，将其包装在未检查的异常中，然后抛出未检查的异常。

１ ． 如果你不确定一个异常，检查API:

java . lang . object 由java.lang.Throwable扩展 由java.lang.Exception扩展 //<-NumberFormatException是一个RuntimeException 由java.lang.IllegalArgumentException扩展 由java.lang.NumberFormatException扩展

2。是的，以及所有扩展它的异常。

3.不需要捕获和抛出相同的异常。在这种情况下，您可以显示一个新的文件对话框。

4所示。FileNotFoundException已经是一个检查异常。

5。如果期望调用someMethod的方法捕获异常，则可以抛出后者。它只是“传球”。使用它的一个例子是，如果你想在你自己的私有方法中抛出它，而在你的公共方法中处理异常。

一个很好的阅读是Oracle文档本身:http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html

Why did the designers decide to force a method to specify all uncaught checked exceptions that can be thrown within its scope? Any Exception that can be thrown by a method is part of the method's public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them. These exceptions are as much a part of that method's programming interface as its parameters and return value. The next question might be: "If it's so good to document a method's API, including the exceptions it can throw, why not specify runtime exceptions too?" Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.

在Java语言规范中还有一些重要的信息:

在throws子句中命名的受控异常类是方法或构造函数的实现者和用户之间契约的一部分。

IMHO的底线是，您可以捕获任何RuntimeException，但不需要这样做，事实上，实现不需要维护抛出的相同的未检查异常，因为这些异常不是契约的一部分。

某个异常是否为“受控异常”与是否捕获它或在捕获块中做了什么无关。它是异常类的属性。Exception的子类，除了RuntimeException及其子类，都是受控异常。

Java编译器迫使您要么捕获已检查的异常，要么在方法签名中声明它们。它本应提高程序的安全性，但大多数人的意见似乎是，它不值得它带来的设计问题。

为什么他们让异常冒泡 起来吗?不是处理错误越快 更好吗?为什么要冒出来?

因为这就是例外的意义所在。如果没有这种可能性，就不需要异常。它们使您能够在您选择的级别上处理错误，而不是强迫您在错误最初发生的低级方法中处理它们。