下面是反对受控异常的一个论点(来自joelonsoftware.com):

The reasoning is that I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's: They are invisible in the source code. Looking at a block of code, including functions which may or may not throw exceptions, there is no way to see which exceptions might be thrown and from where. This means that even careful code inspection doesn't reveal potential bugs. They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.

受控异常最初的形式是试图处理意外事件，而不是失败。值得称赞的目标是突出特定的可预测点(无法连接，文件未找到等)并确保开发者能够处理这些问题。

最初的概念中从未包括的是强制宣布大量系统性和不可恢复的故障。这些失败不能被声明为受控异常。

在代码中失败通常是可能的，EJB、web和Swing/AWT容器已经通过提供最外层的“失败请求”异常处理程序来满足这一点。最基本的正确策略是回滚事务并返回错误。

关键的一点是，运行时异常和受控异常在功能上是等价的。检查异常所能做的处理或恢复是运行时异常所不能做的。

反对“受控”异常的最大争论是大多数异常无法修复。简单的事实是，我们并不拥有发生故障的代码/子系统。我们看不到实现，我们不负责它，也不能修复它。

如果我们的应用程序不是一个数据库..我们不应该试图修复DB。这违反了封装原则。

特别有问题的是JDBC (SQLException)和用于EJB的RMI (RemoteException)。而不是根据最初的“受控异常”概念确定可修复的偶发事件，这些强制普遍存在的系统可靠性问题，实际上是不可修复的，被广泛宣布。

Java设计中的另一个严重缺陷是异常处理应该正确地放在尽可能高的“业务”或“请求”级别。这里的原则是“早扔晚接”。受控异常做的很少，但会阻碍这一点。

我们在Java中有一个明显的问题，即需要数千个不做任何事情的try-catch块，其中很大一部分(40%以上)被错误编码。这些方法几乎都没有实现任何真正的处理或可靠性，但会增加大量的编码开销。

最后，“受控异常”与FP函数式编程几乎不兼容。

他们对“立即处理”的坚持与“延迟捕获”异常处理最佳实践和任何抽象循环/或控制流的FP结构都不一致。

许多人谈论“处理”受控异常，但他们是在胡说八道。在失败后继续使用null、不完整或不正确的数据来假装成功没有处理任何事情。这是最低级的工程/可靠性渎职。

干净利落的失败，是处理异常最基本的正确策略。回滚事务、记录错误和向用户报告“失败”响应是良好的实践——最重要的是，防止不正确的业务数据提交到数据库。

在业务、子系统或请求级别上，异常处理的其他策略是“重试”、“重新连接”或“跳过”。所有这些都是通用的可靠性策略，并且在运行时异常时工作得更好。

最后，失败比使用不正确的数据运行要好得多。继续将导致次要错误，远离原始原因，更难调试;或者最终将导致提交错误的数据。有人会因此被解雇。

看到的: ——http://literatejava.com/exceptions/checked-exceptions-javas-biggest-mistake/

程序员需要知道一个方法可能抛出的所有异常，以便正确地使用它。因此，仅仅用一些异常来打击他并不一定能帮助一个粗心的程序员避免错误。

微小的好处被繁重的成本所抵消(特别是在较大、不太灵活的代码库中，不断修改接口签名是不切实际的)。

Static analysis can be nice, but truly reliable static analysis often inflexibly demands strict work from the programmer. There is a cost-benefit calculation, and the bar needs to be set high for a check that leads to a compile time error. It would be more helpful if the IDE took on the role of communicating which exceptions a method may throw (including which are unavoidable). Although perhaps it would not be as reliable without forced exception declarations, most exceptions would still be declared in documentation, and the reliability of an IDE warning is not so crucial.

In my opinion the checked exceptions are a very fine concept. Unfortunately the most programmers who have worked together we me have another opinion so that the projects have a lot of wrong used exception handling. I have seen that the most programmers create one (only one) exception class, a subclass of RuntimeException. That contains a message, sometimes a multi language key. I have no chance to argument against this. I have the impression that I talk to a wall when I explain them what anti patterns are, what a contracts of a methods are... I'm a little bit disappointed.

但是今天，对所有事情都有一个通用运行时异常的概念显然是一种反模式。他们使用它来检查用户输入。该异常被抛出，以便用户对话框可以从中产生错误消息。但并不是每个方法的调用者都是对话!通过抛出运行时异常，方法的契约被更改但没有声明，因为它不是一个受控异常。

希望他们今天学到了一些东西，并将在另一个地方进行检查(这是有用和必要的)。只使用受控异常不能解决问题，但受控异常会向程序员发出信号，表明他实现了错误的东西。

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

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

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

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

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

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

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

尽管阅读了整页，我仍然找不到一个反对受控异常的合理论点。相反，大多数人都在谈论糟糕的API设计，无论是在一些Java类中还是在他们自己的类中。

这个功能唯一令人讨厌的地方就是原型设计。这可以通过向语言中添加一些机制来解决(例如，一些@supresscheckedexceptions注释)。但是对于常规编程，我认为受控异常是一件好事。