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

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

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

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

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

简而言之:

异常是一个API设计问题。——不多不少。

检查异常的参数:

为了理解受控异常为什么不是好事，让我们把问题转过来问:受控异常什么时候或为什么有吸引力，也就是说，为什么你希望编译器强制声明异常?

答案是显而易见的:有时您需要捕获异常，而这只有在被调用的代码为您感兴趣的错误提供了特定的异常类时才有可能。

因此，受控异常的理由是，编译器强迫程序员声明抛出了哪些异常，希望程序员随后也会记录特定的异常类和导致异常的错误。

但在现实中，往往是一个包装。acme只抛出AcmeException而不抛出特定的子类。然后调用者需要处理、声明或重新发出acmeexception信号，但仍然不能确定是发生了AcmeFileNotFoundError还是发生了AcmePermissionDeniedError。

因此，如果您只对AcmeFileNotFoundError感兴趣，解决方案是向ACME程序员提交一个特性请求，并告诉他们实现、声明和记录AcmeException的子类。

所以为什么要麻烦呢?

因此，即使使用受控异常，编译器也不能强迫程序员抛出有用的异常。这仍然只是API质量的问题。

因此，没有受控异常的语言通常情况不会更糟。程序员可能倾向于抛出一般Error类的非特定实例，而不是AcmeException，但如果他们完全关心API质量，他们终究会学会引入AcmeFileNotFoundError。

总的来说，异常的规范和文档与普通方法的规范和文档没有太大的区别。这些也是一个API设计问题，如果程序员忘记实现或导出一个有用的特性，那么API就需要改进，以便您可以有效地使用它。

如果遵循这条推理线，很明显，在Java等语言中非常常见的声明、捕获和重新抛出异常的“麻烦”通常没有什么价值。

同样值得注意的是，Java VM没有检查过的异常——只有Java编译器检查它们，并且在运行时，类文件的异常声明更改后是兼容的。Java虚拟机的安全性并不是通过受控异常来提高的，而是通过编码风格来提高的。

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

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

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

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

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

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)中，大多数程序员就是不这样做。

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

下面是反对受控异常的一个论点(来自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.