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

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

在代码中失败通常是可能的，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/

Ok... Checked exceptions are not ideal and have some caveat but they do serve a purpose. When creating an API there are specific cases of failures that are contractual of this API. When in the context of a strongly statically typed language such as Java if one does not use checked exceptions then one must rely on ad-hoc documentation and convention to convey the possibility of error. Doing so removes all benefit that the compiler can bring in handling error and you are left completely to the good will of programmers.

因此，一个人删除了Checked异常，比如在c#中所做的，那么如何以编程和结构的方式传达错误的可能性呢?如何通知客户端代码，这样那样的错误可能发生，必须处理?

在处理受控异常时，我听到了各种可怕的事情，它们被滥用了，这是肯定的，但未受控异常也是如此。我说，等几年，当api被堆叠在很多层的时候，你会乞求某种结构化的方法来传达失败。

以异常在API层底部某处抛出的情况为例，因为没有人知道这个错误甚至可能发生，即使它是一种非常合理的错误类型，当调用代码抛出它时(例如FileNotFoundException而不是VogonsTrashingEarthExcept…)在这种情况下，我们是否处理它并不重要，因为没有任何东西可以处理它)。

Many have argued that not being able to load the file was almost always the end of the world for the process and it must die a horrible and painful death. So yeah.. sure ... ok.. you build an API for something and it loads file at some point... I as the user of said API can only respond... "Who the hell are you to decide when my program should crash !" Sure Given the choice where exceptions are gobbled up and leave no trace or the EletroFlabbingChunkFluxManifoldChuggingException with a stack trace deeper than the Marianna trench I would take the latter without a cinch of hesitation, but does this mean that it is the desirable way to deal with exception ? Can we not be somewhere in the middle, where the exception would be recast and wrapped each time it traversed into a new level of abstraction so that it actually means something ?

最后，我看到的大多数争论都是“我不想处理异常，许多人不想处理异常。受控异常迫使我去处理它们，因此我讨厌受控异常。”完全消除这种机制并将其降级到地狱的深渊是愚蠢的，缺乏判断力和远见。

如果我们消除了受控异常，我们也可以消除函数的返回类型，并且总是返回一个“anytype”变量……这样生活就简单多了，不是吗?

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

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

关于受控异常的问题是，按照通常的概念理解，它们并不是真正的异常。相反，它们是API可选返回值。

The whole idea of exceptions is that an error thrown somewhere way down the call chain can bubble up and be handled by code somewhere further up, without the intervening code having to worry about it. Checked exceptions, on the other hand, require every level of code between the thrower and the catcher to declare they know about all forms of exception that can go through them. This is really little different in practice to if checked exceptions were simply special return values which the caller had to check for. eg.[pseudocode]:

public [int or IOException] writeToStream(OutputStream stream) {
    [void or IOException] a= stream.write(mybytes);
    if (a instanceof IOException)
        return a;
    return mybytes.length;
}

由于Java不能选择返回值，或简单的内联元组作为返回值，受控异常是一个合理的响应。

问题是，很多代码，包括大量标准库，在真正的异常情况下滥用了检查过的异常，您可能非常想要在几个级别上捕获这些异常。为什么IOException不是RuntimeException?在其他任何语言中，我都可以让IO异常发生，如果我不做任何处理，我的应用程序将停止，我将获得一个方便的堆栈跟踪来查看。这是最好的结果了。

也许在这个例子中有两个方法，你想从整个写入到流的过程中捕获所有的ioexception，中止该过程并跳转到错误报告代码;在Java中，如果不在每个调用级别添加' throws IOException '，甚至是本身不执行IO的级别，就无法做到这一点。这样的方法不需要知道异常处理;必须为他们的签名添加异常:

不必要地增加耦合; 使接口签名非常容易更改; 使代码可读性降低; 是如此令人讨厌，以至于常见的程序员反应是通过做一些可怕的事情来击败系统，比如' throws Exception '， ' catch (Exception e){} '，或者将所有内容包装在RuntimeException中(这使得调试更加困难)。

然后还有很多可笑的库异常，比如:

try {
    httpconn.setRequestMethod("POST");
} catch (ProtocolException e) {
    throw new CanNeverHappenException("oh dear!");
}

当你不得不用这样可笑的东西把你的代码弄得乱七八糟的时候，也难怪受控异常会受到很多人的讨厌，尽管实际上这只是简单的糟糕的API设计。

另一个特别坏的影响是在控制反转,在组件提供一个回调通用组件B组件希望能够让一个异常抛出的回调回到的地方它称为组件B,但不能因为这样会改变固定的回调接口通过B只能做包装RuntimeException真正的例外,这是更多的异常处理样板来写。

在Java及其标准库中实现的受控异常意味着样板文件、样板文件、样板文件。在一个已经啰嗦的语言中，这不是一个胜利。

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

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

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

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

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

我认为这是一个很好的问题，没有任何争论。我认为第三方库(通常)应该抛出未经检查的异常。这意味着你可以隔离你对库的依赖(也就是说，你既不用重新抛出它们的异常，也不用抛出异常——这通常是不好的做法)。Spring的DAO层就是一个很好的例子。

On the other hand, exceptions from the core Java API should in general be checked if they could ever be handled. Take FileNotFoundException or (my favourite) InterruptedException. These conditions should almost always be handled specifically (i.e. your reaction to an InterruptedException is not the same as your reaction to an IllegalArgumentException). The fact that your exceptions are checked forces developers to think about whether a condition is handle-able or not. (That said, I've rarely seen InterruptedException handled properly!)

还有一件事——RuntimeException并不总是“开发人员出错的地方”。当您尝试使用valueOf创建枚举且没有该名称的枚举时，将抛出非法参数异常。这并不一定是开发者的错误!