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

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

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

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

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

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

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

异常类

当谈到异常时，我总是会参考Eric Lippert的恼人异常博客文章。他将例外情况分为以下几类:

Fatal - These exceptions are not your fault: you cannot prevent then, and you cannot sensibly handle them. For example, OutOfMemoryError or ThreadAbortException. Boneheaded - These exceptions are your fault: you should have prevented them, and they represent bugs in your code. For example, ArrayIndexOutOfBoundsException, NullPointerException or any IllegalArgumentException. Vexing - These exceptions are not exceptional, not your fault, you cannot prevent them, but you'll have to deal with them. They are often the result of an unfortunate design decision, such as throwing NumberFormatException from Integer.parseInt instead of providing an Integer.tryParseInt method that returns a boolean false on parse failure. Exogenous - These exceptions are usually exceptional, not your fault, you cannot (reasonably) prevent them, but you must handle them. For example, FileNotFoundException.

API用户:

不能处理致命或愚蠢的异常。 应该处理令人烦恼的异常，但它们不应该出现在理想的API中。 必须处理外生异常。

已检查的异常

API用户必须处理特定的异常，这是调用方和被调用方之间的方法契约的一部分。契约指定了被调用方期望的参数的数量和类型，调用方期望的返回值类型，以及调用方期望处理的异常。

由于API中不应该存在令人烦恼的异常，因此只有这些外生异常必须作为方法契约的一部分进行检查。相对较少的异常是外生的，因此任何API都应该有相对较少的受控异常。

受控异常是必须处理的异常。处理异常就像吞下它一样简单。在那里!异常被处理。时期。如果开发者想这样处理，没问题。但他不能忽视这个例外，已经得到了警告。

API的问题

但是任何检查了令人烦恼和致命异常的API(例如JCL)都会给API用户带来不必要的压力。必须处理这样的异常，但是要么异常太常见，以至于一开始就不应该是异常，要么在处理它时什么都做不了。这导致Java开发人员讨厌受控异常。

此外，许多api没有适当的异常类层次结构，导致各种非外生异常原因都由单个受控异常类表示(例如IOException)。这也导致Java开发人员讨厌受控异常。

结论

外生异常指的是那些不是您的错、无法预防、并且应该处理的异常。这些构成了所有可能引发的异常的一个小子集。api应该只检查外生异常，所有其他异常都不检查。这将使API更好，给API用户带来更少的压力，从而减少捕获所有、吞咽或重新抛出未经检查的异常的需要。

所以不要讨厌Java和它的受控异常。相反，讨厌那些过度使用受控异常的api。

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

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

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.

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

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

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

在过去的三年中，我一直在与一些开发人员一起开发相对复杂的应用程序。我们有一个代码库，它经常使用检查异常，并进行适当的错误处理，而其他一些代码库则没有。

So far, I have it found easier to work with the code base with Checked Exceptions. When I am using someone else's API, it is nice that I can see exactly what kind of error conditions I can expect when I call the code and handle them properly, either by logging, displaying or ignoring (Yes, there is valid cases for ignoring exceptions, such as a ClassLoader implementation). That gives the code I am writing an opportunity to recover. All runtime exceptions I propagate up until they are cached and handled with some generic error handling code. When I find a checked exception that I don't really want to handle at a specific level, or that I consider a programming logic error, then I wrap it into a RuntimeException and let it bubble up. Never, ever swallow an exception without a good reason (and good reasons for doing this are rather scarce)

当我使用没有检查异常的代码库时，它使我在调用函数时很难预先知道我期望什么，这可能会严重破坏一些东西。

当然，这完全取决于开发者的偏好和技能。编程和错误处理的两种方式可能同样有效(或无效)，所以我不会说只有一种方法。

总而言之，我发现使用受控异常更容易，特别是在有很多开发人员的大型项目中。

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

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