《有效的Java异常》一文很好地解释了什么时候使用未检查的异常，什么时候使用已检查的异常。以下是那篇文章中的一些引语，以突出其要点:

应急预案: 一种期望的条件，要求方法提供可根据该方法的预期目的来表达的替代响应。方法的调用者期望这些类型的条件，并有一个策略来处理它们。 错: 一种计划外的情况，阻止方法实现其预期目的，如果不参考方法的内部实现，则无法描述该情况。

(SO不支持表格，所以你可能想从原始页面阅读以下内容…)

Contingency Is considered to be: A part of the design Is expected to happen: Regularly but rarely Who cares about it: The upstream code that invokes the method Examples: Alternative return modes Best Mapping: A checked exception Fault Is considered to be: A nasty surprise Is expected to happen: Never Who cares about it: The people who need to fix the problem Examples: Programming bugs, hardware malfunctions, configuration mistakes, missing files, unavailable servers Best Mapping: An unchecked exception

Robert C. Martin在他的著作《Clean Code》中也不推荐使用受控异常，他认为受控异常违反了开闭原则:

什么价格?受控异常的价格是Open/Closed Principle1侵犯。如果从方法抛出checked异常 在您的代码中，并且catch高于三级，您必须声明 实例之间的每个方法签名中的异常 抓住。这意味着在软件的低级别上的更改可以 在许多更高级别上强制更改签名。变更的模块 必须重建和重新部署，即使他们不关心 改变了。

没有人提到的一件重要的事情是它如何干扰接口和lambda表达式。

假设您定义了MyAppException扩展异常。它是由应用程序抛出的所有异常继承的顶级异常。在某些地方，您不想对特定的异常做出反应，您希望调用者解决它，因此您声明throws MyAppException。

一切看起来都很好，直到你想使用别人的界面。显然它们没有声明抛出MyAppException的意图，所以编译器甚至不允许你调用在那里声明抛出MyAppException的方法。这对于java.util.function来说尤其痛苦。

但是，如果您的异常扩展了RuntimeException，那么接口就不会有问题。如果愿意，可以在JavaDoc中提到异常。但除此之外，它只是无声地穿过任何东西。当然，这意味着它可以终止你的申请。但是在很多企业软件中都有异常处理层，未检查的异常可以省去很多麻烦。

良好的证明Checked Exception是不需要的:

A lot of framework that does some work for Java. Like Spring that wraps JDBC exception to unchecked exceptions, throwing messages to the log Lot of languages that came after java, even on top on java platform - they do not use them Checked exceptions, it is kind prediction about how the client would use the code that throws an exception. But a developer who writes this code would never know about the system and business that client of code is working in. As an example Interfcace methods that force to throw checked exception. There are 100 implementation over the system, 50 or even 90 of implementations do not throw this exception, but the client still must to catch this exception if he user reference to that interface. Those 50 or 90 implementations tend to handle those exceptions inside themself, putting exception to the log (and this is good behavior for them). What we should do with that? I would better have some background logic that would do all that job - sending message to the log. And If I, as a client of code, would feel I need handle the exception - I will do it. I may forget about it, right - but if I use TDD, all my steps are covered and I know what I want. Another example when I'm working with I/O in java, it forces me to check all exception, if file does not exists? what I should do with that? If it does not exists, the system would not go to the next step. The client of this method, would not get expected content from that file - he can handle Runtime Exception, otherwise I should first check Checked Exception, put a message to log, then throw exception up out form the method. No...no - I would better do it automatically with RuntimeEception, that does it / lits up automatically. There is no any sense to handle it manually - I would be happy I saw an error message in the log (AOP can help with that.. something that fixes java). If, eventually, I deice that system should shows pop-up message to the end user - I will show it, not a problem.

我很高兴java能让我选择使用什么，当使用核心库时，比如I/O。Like提供了相同类的两个副本——一个用RuntimeEception包装。然后我们可以比较人们会使用什么。但是现在，很多人会选择java或其他语言之上的框架。比如Scala, JRuby等等。许多人相信SUN是对的。

我最初同意你的观点，因为我一直支持受控异常，并开始思考为什么我不喜欢在. net中没有受控异常。但后来我意识到我并不喜欢受控异常。

回答您的问题，是的，我喜欢我的程序显示堆栈跟踪，最好是非常难看的跟踪。我希望应用程序爆发成一堆您希望看到的最糟糕的错误消息。

原因是，如果出现这种情况，我必须修复它，而且必须马上修复。我想马上知道有什么问题。

您实际处理了多少次异常?我说的不是捕获异常——我说的是处理异常?这样写太简单了:

try {
  thirdPartyMethod();
} catch(TPException e) {
  // this should never happen
}

我知道你可能会说这是一种糟糕的实践，“答案”是做一些异常(让我猜猜，记录它?)，但在现实世界(tm)中，大多数程序员就是不这样做。

所以，是的，我不想捕捉异常，如果我没有必要这样做，我希望我的程序在我搞砸的时候爆炸。默默的失败是最糟糕的结果。

的确，受控异常一方面增加了程序的健壮性和正确性(你被迫对接口做出正确的声明——方法抛出的异常基本上是一种特殊的返回类型)。另一方面，你面临的问题是，由于异常“冒出来”，当你改变一个方法抛出的异常时，你经常需要改变大量的方法(所有的调用者，以及调用者的调用者，等等)。

Java中的受控异常不能解决后一个问题;c#和VB。我们把孩子和洗澡水一起倒掉。

OOPSLA 2005论文(或相关技术报告)中描述了一种折衷的好方法。

简而言之，它允许你说:方法g(x)像f(x)一样抛出，这意味着g抛出f抛出的所有异常。瞧，没有级联更改问题的受控异常。

虽然这是一篇学术论文，但我还是鼓励你阅读(部分)它，因为它很好地解释了受控异常的优点和缺点。