未经检查的异常，本来会更好的检查答案

【问题标题】：unchecked exception that would have been better as checked未经检查的异常，本来会更好的检查
【发布时间】：2012-06-01 21:19:17
【问题描述】：

我意识到在 Java 中检查异常与未检查异常的相对优点有been ample discussion，我无意重新讨论整个辩论。

相反，我想问一个非常具体的问题，这是我在阅读 Joshua Bloch 的 Effective Java，第 2 版时想到的。在阅读时，我注意到在 Item 59（“避免不必要地使用受检异常”）中，Joshua 在 Java API 中给出了一个使用受检异常的示例。具体来说，在Object：

protected Object clone()
            throws CloneNotSupportedException

...然后争辩说它应该是一个未经检查的异常。

如果使用 API 的程序员不能做得更好，那么未经检查的异常会更合适。未能通过此测试的异常示例之一是 CloneNotSupportedException。它由 Object.clone 抛出，它应该只在实现 Cloneable 的对象上调用（第 11 项）。在实践中，catch 块几乎总是具有断言失败的特征。异常的检查性质对程序员没有任何好处，但它需要努力并使程序复杂化。

然后我查看他是否有相反的示例，但我找不到。

所以我想问一下是否有人可以提供一个使用未经检查的异常的 Java 示例 API，但在哪里检查的异常会是更好的选择，并解释原因。一个真实的例子会更好，但我愿意接受一个人为的例子，如果这也能说明问题。

编辑：对于那些投票以非建设性的方式结束此内容的人，我想明确表示我不是在寻找意见、辩论、争论或扩展讨论。我也没有进行民意调查。相反，我正在寻找可以对收益如何超过成本进行清晰分析的示例参考。（其中隐含的是承认有成本。）也就是说，我怀疑这个问题的性质是否使这成为可能。我认为如果 Jon Skeet 做不到，那也不太可能做到。所以也许你是对的。必要时关闭。

编辑：虽然我不为所动，但我将把这个奖励给乔恩，只是因为我的接受率。

【问题讨论】：

标签： java exception language-design api-design effective-java

【解决方案1】：

是的，很容易：Integer.parseInt 抛出未选中的 NumberFormatException。

但是，如果您曾经解析过可能不正确的数据，则绝对应该考虑捕获异常 - 您很可能能够忽略该数据，或者报告它并继续前进。这不像 Java 有 .NET 的 Int32.TryParse 等价物，它可以让您轻松忽略不良数据。基本上你需要知道你需要捕获异常，而不需要编译器的挑衅。呸。

【讨论】：

我完全同意。当您在编码并进入“区域”时，很容易错过某个等待弹出并喊“pwn3d！”的异常。要么是因为你忘了抓住它，要么是因为你不知道你可能需要抓住它......
感谢您的快速回复，乔恩。你选择了一个不困扰我的例子。我对 JavaDoc 中提到的异常感到满意，并且我很感激允许我选择处理问题的范围。您认为每个示例都会归结为相同的权衡吗？
@pohl：假设您在您的一种方法中调用 Integer.parseInt，但忘记捕获或声明它。那时，任何 that 方法的调用者都不知道会发生什么。对这种情况还满意吗？
好问题。我敢肯定，我会因为提供糟糕的产品而感到难过。我想如果将此作为检查异常完全免除我对不良输入的鲁棒性负担，我会发现这种思路令人信服。不过，我认为不会。至少，你的例子足以让我望而却步。
ArithmeticException (docs.oracle.com/javase/7/docs/api/java/lang/…) 将是另一个类似的例子。