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

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

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

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

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

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

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

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

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

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

我读了很多关于异常处理的书，即使(大多数时候)我不能真的说我对受控异常的存在感到高兴或悲伤，这是我的看法:在低级代码(IO，网络，OS等)中受控异常，在高级api /应用程序级别中未受控异常。

即使在它们之间没有那么容易划清界限，我发现在同一屋檐下集成几个api /库而不始终包装大量的检查异常是非常烦人/困难的，但另一方面，有时强制捕获一些异常并提供一个在当前上下文中更有意义的不同异常是有用/更好的。

The project I'm working on takes lots of libraries and integrates them under the same API, API which is completely based on unchecked exceptions.This frameworks provides a high-level API which in the beginning was full of checked exceptions and had only several unchecked exceptions(Initialization Exception, ConfigurationException, etc) and I must say was not very friendly. Most of the time you had to catch or re-throw exceptions which you don't know how to handle, or you don't even care(not to be confused with you should ignore exceptions), especially on the client side where a single click could throw 10 possible (checked) exceptions.

The current version(3rd one) uses only unchecked exceptions, and it has a global exception handler which is responsible to handle anything uncaught. The API provides a way to register exception handlers, which will decide if an exception is considered an error(most of the time this is the case) which means log & notify somebody, or it can mean something else - like this exception, AbortException, which means break the current execution thread and don't log any error 'cause it is desired not to. Of course, in order to work out all custom thread must handle the run() method with a try {...} catch(all).

公共无效运行(){

try {
     ... do something ...
} catch (Throwable throwable) {
     ApplicationContext.getExceptionService().handleException("Handle this exception", throwable);
}

}

如果您使用WorkerService来安排作业(Runnable, Callable, Worker)，这是不必要的，它会为您处理一切。

当然，这只是我的个人观点，它可能不是正确的，但对我来说这是一个很好的方法。我将在发布项目后看看我认为对我有好处的东西，对其他人也有好处……：）

我在c2.com上写的文章与原来的CheckedExceptionsAreIncompatibleWithVisitorPattern基本没有变化

总而言之:

访问者模式(Visitor Pattern)及其亲属是一类接口，其中间接调用者和接口实现都知道异常，但接口和直接调用者组成了一个不知道异常的库。

CheckedExceptions的基本假设是，所有声明的异常都可以从调用带有该声明的方法的任何点抛出。VisitorPattern揭示了这个假设是错误的。

在这种情况下，受控异常的最终结果是大量无用的代码，本质上是在运行时删除编译器的受控异常约束。

至于根本问题:

我的总体想法是，顶级处理程序需要解释异常并显示适当的错误消息。我几乎总是看到IO异常、通信异常(由于某些原因api可以区分)或任务致命错误(程序错误或备份服务器上的严重问题)，所以如果我们允许对严重的服务器问题进行堆栈跟踪，这应该不会太难。