在 API 中看到检查预期并不罕见，最著名的例子之一是 Closeable.close() 中的 IOException .经常处理这个异常真的让我很烦。更烦人的例子出现在我们的一个项目中。它由几个组件组成，每个组件声明特定的检查异常。问题(在我看来)是在设计时并不完全知道某些异常是什么。因此，例如，组件 Configurator 声明了 ConfiguratorExeption。当我问为什么不只使用未经检查的异常时，我被告知我们希望我们的应用程序健壮并且不会在运行时崩溃。但这似乎是一个无力的论据，因为:
- 这些异常中的大多数实际上会导致应用无法使用。是的，它不会爆炸，但除了用消息淹没日志外，它什么也做不了。
- 这些异常并不具体，实际上意味着“发生了不好的事情”。客户应该如何恢复？
- 事实上，所有的恢复都来自于记录异常然后吞噬它。这是在大型
try-catch语句中执行的。
我认为，这是一个反复出现的模式。但检查异常仍然在 API 中广泛使用。这是什么原因？是否有某些类型的 API 更适合检查异常？
最佳答案
有很多controversy围绕这个问题。
看看这篇关于该主题的经典文章 http://www.mindview.net/Etc/Discussions/CheckedExceptions
我个人倾向于使用 Runtime 异常，并开始考虑在您的 API 中使用检查异常是一个坏主意。
事实上，一些非常流行的 Java API 已经开始做同样的事情，例如，Hibernate 从第 3 版，即 Spring 框架中放弃了对运行时的检查异常的使用也赞成使用运行时而不是检查异常。
关于java - 在外部 API 中使用检查异常是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3357296/