我认为这是一个很好的问题，没有任何争论。我认为第三方库(通常)应该抛出未经检查的异常。这意味着你可以隔离你对库的依赖(也就是说，你既不用重新抛出它们的异常，也不用抛出异常——这通常是不好的做法)。Spring的DAO层就是一个很好的例子。

On the other hand, exceptions from the core Java API should in general be checked if they could ever be handled. Take FileNotFoundException or (my favourite) InterruptedException. These conditions should almost always be handled specifically (i.e. your reaction to an InterruptedException is not the same as your reaction to an IllegalArgumentException). The fact that your exceptions are checked forces developers to think about whether a condition is handle-able or not. (That said, I've rarely seen InterruptedException handled properly!)

还有一件事——RuntimeException并不总是“开发人员出错的地方”。当您尝试使用valueOf创建枚举且没有该名称的枚举时，将抛出非法参数异常。这并不一定是开发者的错误!

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

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

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

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.

试图解决这个尚未解决的问题:

如果抛出RuntimeException子类而不是Exception子类，那么您如何知道应该捕获什么?

恕我直言，这个问题包含似是而非的推理。仅仅因为API告诉你它抛出了什么并不意味着你在所有情况下都以相同的方式处理它。 换句话说，您需要捕获的异常取决于您使用抛出异常的组件的上下文。

例如:

如果我正在为数据库编写连接测试程序，或者编写检查用户输入XPath的有效性的程序，那么我可能希望捕获并报告操作抛出的所有已检查和未检查的异常。

然而，如果我正在编写一个处理引擎，我可能会以与NPE相同的方式处理XPathException (checked):我将让它运行到工作线程的顶部，跳过该批处理的其余部分，记录问题(或将其发送给支持部门进行诊断)，并为用户联系支持人员留下反馈。

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#中也能很好地工作。

我之前在博客上写过。

简而言之:

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

检查异常的参数:

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

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

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

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

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

所以为什么要麻烦呢?

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

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

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

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

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