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

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

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

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

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

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

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

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

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

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

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

这并不是反对受控异常的纯概念，但是Java用于受控异常的类层次结构是一个畸形秀。我们总是简单地称这些东西为“异常”——这是正确的，因为语言规范也这样称呼它们——但是异常在类型系统中是如何命名和表示的呢?

By the class Exception one imagines? Well no, because Exceptions are exceptions, and likewise exceptions are Exceptions, except for those exceptions that are not Exceptions, because other exceptions are actually Errors, which are the other kind of exception, a kind of extra-exceptional exception that should never happen except when it does, and which you should never catch except sometimes you have to. Except that's not all because you can also define other exceptions that are neither Exceptions nor Errors but merely Throwable exceptions.

哪些是“已检查”异常?可抛出异常是受控异常，除非它们也是错误，是未检查的异常，然后是异常，也是可抛出异常，是受控异常的主要类型，除了有一个例外，那就是if它们也是runtimeexception，因为那是另一种未检查的异常。

What are RuntimeExceptions for? Well just like the name implies, they're exceptions, like all Exceptions, and they happen at run-time, like all exceptions actually, except that RuntimeExceptions are exceptional compared to other run-time Exceptions because they aren't supposed to happen except when you make some silly error, although RuntimeExceptions are never Errors, so they're for things that are exceptionally erroneous but which aren't actually Errors. Except for RuntimeErrorException, which really is a RuntimeException for Errors. But aren't all exceptions supposed to represent erroneous circumstances anyway? Yes, all of them. Except for ThreadDeath, an exceptionally unexceptional exception, as the documentation explains that it's a "normal occurrence" and that that's why they made it a type of Error.

Anyway, since we're dividing all exceptions down the middle into Errors (which are for exceptional execution exceptions, so unchecked) and Exceptions (which are for less exceptional execution errors, so checked except when they're not), we now need two different kinds of each of several exceptions. So we need IllegalAccessError and IllegalAccessException, and InstantiationError and InstantiationException, and NoSuchFieldError and NoSuchFieldException, and NoSuchMethodError and NoSuchMethodException, and ZipError and ZipException.

只不过，即使检查了异常，也总有(相当简单的)方法可以欺骗编译器，在不检查的情况下抛出异常。如果你这样做，你可能会得到一个不确定的throwableexception，除非在其他情况下，它可能抛出一个意外的dexception，或一个未知的异常(与未知的错误无关，只针对“严重的异常”)，或一个ExecutionException，或一个InvocationTargetException，或一个ExceptionInInitializerError。

哦，我们一定不能忘记Java 8时髦的新UncheckedIOException，这是一个RuntimeException异常，设计用来通过包装由I/O错误(不会引起IOError异常，尽管也存在)引起的已检查的IOException异常来抛出异常检查的概念，这些异常异常难以处理，因此您需要它们不被检查。

由于Java !

Anders在软件工程电台的第97集中谈到了受控异常的陷阱，以及他为什么把它们排除在c#之外。

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

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

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.

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”变量……这样生活就简单多了，不是吗?