我意识到有 been ample discussion Java 中检查异常与未检查异常的相对优点，我无意重新讨论整个辩论。
相反，我想问一个非常具体的问题，这是我在阅读 Joshua Bloch 的 Effective Java，第 2 版时想到的。在阅读时，我注意到在第 59 项(“避免不必要地使用已检查异常”)中，Joshua 在 Java API 中给出了一个使用已检查异常的示例。具体来说，在 Object 中:
protected Object clone()
throws CloneNotSupportedException
...然后争辩说它应该是一个未经检查的异常。
If the programmer using the API can do no better, an unchecked exception would be more appropriate. One example of an exception that fails this test is CloneNotSupportedException. It is thrown by Object.clone, which should be invoked only on objects that implement Cloneable (Item 11). In practice, the catch block almost always has the character of an assertion failure. The checked nature of the exception provides no benefit to the programmer, but it requires effort and complicates programs.
然后我看他是否有相反的例子，但我找不到。
所以我想问问是否有人可以在 Java 中给出一个使用未检查异常的示例 API，但检查异常会是更好的选择，并解释原因。一个真实世界的例子会更好，但我愿意接受一个人为的例子，如果它也能说明问题的话。
编辑:对于那些投票将其视为非建设性的关闭的人，我想明确表示我不是在寻求意见、辩论、争论或扩展讨论。我也不参加投票。相反，我正在寻找对 yield 如何超过成本进行清晰分析的示例引用。 (其中隐含的是承认存在成本。)也就是说，我怀疑这个问题的性质是否使这成为可能。我估计如果 Jon Skeet 做不到，那也不太可能做到。所以也许你是对的。如果必须，请关闭。
编辑:尽管我对回复无动于衷，但我还是会把这个奖励给 Jon，只是为了我的接受率。
最佳答案
是的，很简单:Integer.parseInt抛出未经检查的 NumberFormatException。
但是，如果您曾经解析过潜在的坏数据，您绝对应该考虑捕获异常 - 您很可能能够忽略该数据，或者报告它并继续。它不像 Java 有等同于 .NET 的 Int32.TryParse这让您轻松忽略坏数据。基本上你需要知道你需要在没有编译器挑衅的情况下捕获异常。咕噜咕噜
关于java - 未检查的异常，如果检查会更好，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10857505/