Artima发表了一篇对。net架构师之一Anders Hejlsberg的采访，其中尖锐地讨论了反对受控异常的论点。品性差的人:

The throws clause, at least the way it's implemented in Java, doesn't necessarily force you to handle the exceptions, but if you don't handle them, it forces you to acknowledge precisely which exceptions might pass through. It requires you to either catch declared exceptions or put them in your own throws clause. To work around this requirement, people do ridiculous things. For example, they decorate every method with, "throws Exception." That just completely defeats the feature, and you just made the programmer write more gobbledy gunk. That doesn't help anybody.

我们已经看到了c#首席架构师的一些参考。

下面是Java人员关于何时使用受控异常的另一种观点。他承认了其他人提到的许多负面因素: 有效的异常

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

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

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

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

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

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

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

受控异常的一个问题是，如果一个接口的一个实现使用了它，异常通常会附加到该接口的方法上。

受控异常的另一个问题是它们容易被滥用。java.sql就是一个完美的例子。连接的close()方法。它可以抛出一个SQLException，即使您已经显式地声明您已经完成了连接。close()可能传达了哪些您所关心的信息?

通常，当我关闭()一个连接*时，它看起来像这样:

try {
    conn.close();
} catch (SQLException ex) {
    // Do nothing
}

另外，不要让我开始各种解析方法和NumberFormatException... .NET的TryParse，它不抛出异常，使用起来要容易得多，以至于不得不回到Java(我工作的地方同时使用Java和c#)。

*作为额外的注释，PooledConnection的connection .close()甚至不关闭连接，但您仍然必须捕获SQLException，因为它是一个已检查异常。

正如人们已经说过的，Java字节码中不存在受控异常。它们只是一种编译器机制，与其他语法检查没有什么不同。我看到很多受控异常，就像我看到编译器抱怨一个冗余的条件:if(true) {a;b;}。这很有帮助，但我可能是故意这么做的，所以我忽略你的警告。

事实是，如果你强制执行受控异常，你将无法强迫每个程序员“做正确的事情”，而其他人现在都是附带损害，他们只是因为你制定的规则而讨厌你。

修复坏程序!不要试图修改语言来阻止它们!对于大多数人来说，“对异常做一些事情”实际上只是告诉用户它。我也可以告诉用户一个未检查的异常，所以不要让您的已检查异常类出现在我的API中。

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