我认为这是一个很好的问题，没有任何争论。我认为第三方库(通常)应该抛出未经检查的异常。这意味着你可以隔离你对库的依赖(也就是说，你既不用重新抛出它们的异常，也不用抛出异常——这通常是不好的做法)。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创建枚举且没有该名称的枚举时，将抛出非法参数异常。这并不一定是开发者的错误!

简而言之:

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

检查异常的参数:

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

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

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

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

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

所以为什么要麻烦呢?

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

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

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

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

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

在过去的三年中，我一直在与一些开发人员一起开发相对复杂的应用程序。我们有一个代码库，它经常使用检查异常，并进行适当的错误处理，而其他一些代码库则没有。

So far, I have it found easier to work with the code base with Checked Exceptions. When I am using someone else's API, it is nice that I can see exactly what kind of error conditions I can expect when I call the code and handle them properly, either by logging, displaying or ignoring (Yes, there is valid cases for ignoring exceptions, such as a ClassLoader implementation). That gives the code I am writing an opportunity to recover. All runtime exceptions I propagate up until they are cached and handled with some generic error handling code. When I find a checked exception that I don't really want to handle at a specific level, or that I consider a programming logic error, then I wrap it into a RuntimeException and let it bubble up. Never, ever swallow an exception without a good reason (and good reasons for doing this are rather scarce)

当我使用没有检查异常的代码库时，它使我在调用函数时很难预先知道我期望什么，这可能会严重破坏一些东西。

当然，这完全取决于开发者的偏好和技能。编程和错误处理的两种方式可能同样有效(或无效)，所以我不会说只有一种方法。

总而言之，我发现使用受控异常更容易，特别是在有很多开发人员的大型项目中。

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

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

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

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

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

我不想重复所有(许多)反对受控异常的原因，我只选一个。我已经记不清写了多少次这段代码了:

try {
  // do stuff
} catch (AnnoyingcheckedException e) {
  throw new RuntimeException(e);
}

99%的情况下我对此无能为力。最后，块进行必要的清理(或者至少它们应该这样做)。

我也记不清有多少次看到这样的场景:

try {
  // do stuff
} catch (AnnoyingCheckedException e) {
  // do nothing
}

为什么?因为有人要处理这件事，而且很懒。错了吗?确定。会发生吗?绝对的。如果这是一个未检查的异常呢?应用程序就会死掉(这比吞下一个异常更好)。

然后我们有一些令人愤怒的代码，它使用异常作为一种流控制形式，就像java.text.Format所做的那样。Bzzzt。错了。用户在表单的数字字段中输入“abc”也不例外。

好吧，我想这是三个原因。

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

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

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

例如:

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

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