unchecked异常_为什么要在Java中使用Unchecked异常而不是Checked异常

unchecked异常

关于检查与未检查的异常的争论可以追溯到过去。有人说这是Java包含的最佳功能之一。其他人则说这是他们最大的错误之一[ 1 ]。

辩论似乎结束了。在这篇文章中，我将尝试包含涉及该主题的文章和书籍的链接。我不是专家，但是我会尽力向您解释为什么我得出这个结论。

所以，我们正在谈论，

未检查的异常：

表示程序中的缺陷（错误）–通常将无效参数传递给非私有方法。 引用Gosling，Arnold和Holmes的《 Java编程语言》：“未经检查的运行时异常表示的条件通常可以反映程序逻辑中的错误，并且无法在运行时合理地恢复。”
是RuntimeException的子类，通常使用IllegalArgumentException，NullPointerException或IllegalStateException实现
一个方法没有义务为由其实现引发的未经检查的异常建立策略（并且它们几乎总是不这样做）

检查异常：

表示程序无法直接控制的区域中的无效条件（无效的用户输入，数据库问题，网络中断，文件缺失）
是Exception的子类
一个方法必须为由其实现抛出的所有检查的异常建立一个策略（将检查的异常进一步传递到堆栈中，或以某种方式进行处理）

以上是Java实践页面[ 2 ]中所讲述的。

在我从事的许多项目中，我看到了不同的编码方式和各种不同的策略，代码格式，类命名风格，数据库和技术。保持不变的一件事是例外。所有项目都有自定义异常，这些异常是通过扩展Exception类而创建的！

我敢肯定，我们大多数人都知道检查和未检查异常之间的区别，但是很少有人在使用它们之前会仔细考虑。我希望所有详细信息都在单个页面中列出，以便说服我的团队改用“未经检查的异常”。

罗伯特·C·马丁（Robert C. Martin）在他的著名著作《 干净的代码：敏捷软件技巧手册》 [ 3 ]中写下了以下几行，以支持“未检查的异常”。

辩论结束了。 多年来，Java程序员一直在争论 检查异常 的好处和责任 。在 Java 的第一个版本中引入检查异常时 ，它们似乎是一个好主意。 每个方法的签名都会列出 它可以传递给调用方的 所有 异常。 而且，这些例外是该类型的一部分

该方法。 如果签名与您的 代码 不匹配，则您的 代码 将无法编译 。

当时，我们认为检查异常是个好主意； 是的，它们可以 带来一些好处。 但是，现在很明显，对于 强大的软件来说 ，它们不是必需的 。 C＃没有经过检查的异常，尽管进行了英勇的尝试，但C ++ 也没有。 Python或Ruby都没有。 但是有可能用所有 这些语言 编写健壮的软件 。 因为是这种情况，所以我们必须（真的）决定是否应该检查 异常。

如果您正在编写关键库，则检查异常有时会很有用：您 必须捕获它们。 但是在一般应用程序开发中，依赖项成本大于 收益

最后一行是最重要的，他谈到了一般的应用程序开发，让我们举个例子，

如果必须使用DOM解析器读取XML文件，则需要处理一些经过检查的异常[ 5 ]，例如ParserConfigurationException，SAXException和IOException。 API开发人员认为，如果XML无效，他们应该通知，以便API的使用者（即应用程序开发人员）可以决定如何处理这种情况。

现在，如果您有其他选择来进行普通逻辑处理，则可以这样做，否则，应该捕获这些已检查的异常并抛出和未检查的异常。这样，方法签名也将很干净，我们指出如果XML无效，我们将无法做很多事情，并且我们将停止处理。让写在顶层的错误处理程序对做什么做出适当的决定。

因此，我们需要做的就是通过扩展RuntimeException来创建自定义异常类。

在Oracle托管的Java教程中，有一个关于该辩论的有趣页面[ 4 ]，该页面以该行结尾。 如果可以合理地期望客户端从异常中恢复，请将其设置为已检查的异常。 如果客户端无法采取任何措施来从异常中恢复，请将其设置为未经检查的异常。

我也发现很少文章支持这一点，

霍华德·刘易斯·希普的检查异常的悲剧
杰德·卫斯理·史密斯（Jed Wesley-Smith）是个例外
检查过的异常我爱你，但你得走了 Misko Hevery

另外，很少有文章介绍一般的最佳最佳实践，

Vineet Reynolds的准则异常处理
异常处理反模式作者：Tim McCune
杰出实践，作者Brian Goetz 异常处理的最佳实践作者：Gunjan Doshi

参考： 为什么我们的JCG合作伙伴会在Java中使用Unchecked异常而不是Java Checked异常面向对象的生活博客中的Manu PK。