SNR

首先，检查异常降低了代码的“信噪比”。Anders Hejlsberg也谈到了命令式编程和声明式编程，这是一个类似的概念。不管怎样，考虑下面的代码片段:

在Java中从非UI线程更新UI:

try {  
    // Run the update code on the Swing thread  
    SwingUtilities.invokeAndWait(() -> {  
        try {
            // Update UI value from the file system data  
            FileUtility f = new FileUtility();  
            uiComponent.setValue(f.readSomething());
        } catch (IOException e) {  
            throw new UncheckedIOException(e);
        }
    });
} catch (InterruptedException ex) {  
    throw new IllegalStateException("Interrupted updating UI", ex);  
} catch (InvocationTargetException ex) {
    throw new IllegalStateException("Invocation target exception updating UI", ex);
}

在c#中从非UI线程更新UI:

private void UpdateValue()  
{  
   // Ensure the update happens on the UI thread  
   if (InvokeRequired)  
   {  
       Invoke(new MethodInvoker(UpdateValue));  
   }  
   else  
   {  
       // Update UI value from the file system data  
       FileUtility f = new FileUtility();  
       uiComponent.Value = f.ReadSomething();  
   }  
}  

这对我来说清楚多了。当您开始在Swing中做越来越多的UI工作时，检查异常开始变得非常烦人和无用。

监狱打破

即使要实现最基本的实现，比如Java的List接口，作为契约式设计工具的受控异常也行不通。考虑一个由数据库、文件系统或任何其他抛出受控异常的实现支持的列表。唯一可能的实现是捕获已检查异常，并将其作为未检查异常重新抛出:

@Override
public void clear()  
{  
   try  
   {  
       backingImplementation.clear();  
   }  
   catch (CheckedBackingImplException ex)  
   {  
       throw new IllegalStateException("Error clearing underlying list.", ex);  
   }  
}  

现在你要问所有这些代码的意义是什么?被检查的异常只是增加了噪音，异常被捕获但没有处理，契约式设计(就被检查的异常而言)已经失效。

结论

捕获异常与处理异常是不同的。 受控异常会给代码添加噪音。 没有它们，异常处理在c#中也能很好地工作。

我之前在博客上写过。

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

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

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

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

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

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

这篇文章是我读过的关于Java异常处理的最好的文章。

它更倾向于未检查的异常，而不是已检查的异常，但这个选择的解释非常透彻，并基于强有力的论据。

我不想在这里引用太多的文章内容(最好是整体阅读)，但它涵盖了这个线程中未检查异常倡导者的大部分论点。尤其是这个论点(似乎很受欢迎):

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

作者“回应”:

It is absolutely incorrect to assume that all runtime exceptions should not be caught and allowed to propagate to the very "top" of the application. (...) For every exceptional condition that is required to be handled distinctly - by the system/business requirements - programmers must decide where to catch it and what to do once the condition is caught. This must be done strictly according to the actual needs of the application, not based on a compiler alert. All other errors must be allowed to freely propagate to the topmost handler where they would be logged and a graceful (perhaps, termination) action will be taken.

主要的思想或文章是:

当涉及到软件中的错误处理时，唯一安全且正确的假设是，存在的每个子程序或模块都可能发生故障!

因此，如果“没有人知道这个错误甚至可能发生”，那么这个项目就有问题了。像作者建议的那样，这种异常至少应该由最通用的异常处理程序来处理(例如，处理所有没有更特定的处理程序处理的异常)。

很遗憾，似乎没有多少人发现这篇伟大的文章:-(。我衷心建议每一个犹豫哪种方法更好的人花点时间阅读它。

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

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.

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

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

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