Java理论与实践: 关于异常的争论 - 编程入门网
| 适应的异常。换句话说，一个方法所抛出的异常应 该在一个抽象层次上定义，该抽象层次与该方法做什么相一致，而不一定与方法 的底层实现细节相一致。例如，一个从文件、数据库或者 JNDI 装载资源的方法 在不能找到资源时，应该抛出某种 ResourceNotFound 异常（通常使用异常链来 保存隐含的原因），而不是更底层的 IOException 、 SQLException 或者 NamingException 。
重新考察非检查型异常的正统观点 最近，几位受尊敬的专家，包括 Bruce Eckel 和 Rod Johnson，已经公开声 明尽管他们最初完全同意检查型异常的正统观点，但是他们已经认定排他性使用 检查型异常的想法并没有最初看起来那样好，并且对于许多大型项目，检查型异 常已经成为一个重要的问题来源。Eckel 提出了一个更为极端的观点，建议所有 的异常应该是非检查型的；Johnson 的观点要保守一些，但是仍然暗示传统的优 先选择检查型异常是过分的。（值得一提的是，C# 的设计师在语言设计中选择 忽略检查型异常，使得所有异常都是非检查型的，因而几乎可以肯定他们具有丰 富的 Java 技术使用经验。但是，后来他们的确为检查型异常的实现留出了空间 。） Java理论与实践: 关于异常的争论(2)时间:2010-12-21 IBM Brian Goetz对于检查型异常的一些批评 Eckel 和 Johnson 都指出了一个关于检查型异常的相似的问题清单；一些是 检查型异常的内在属性，一些是检查型异常在 Java 语言中的特定实现的属性， 还有一些只是简单的观察，主要是关于检查型异常的广泛的错误使用是如何变为 一个严重的问题，从而导致该机制可能需要被重新考虑。 检查型异常不适当地暴露实现细节 您已经有多少次看见（或者编写）一个抛出 SQLException 或者 IOException 的方法，即使它看起来与数据库或者文件毫无关系呢？对于开发人 员来说，在一个方法的最初实现中总结出可能抛出的所有异常并且将它们增加到 方法的 throws 子句（许多 IDE 甚至帮助您执行该任务）是十分常见的。这种 直接方法的一个问题是它违反了 Bloch 的 第 43 条 —— 被抛出的异常所位于 的抽象层次与抛出它们的方法不一致。 一个用于装载用户概要的方法，在找不到用户时应该抛出 NoSuchUserException ，而不是 SQLException —— 调用者可以很好地预料到 用户可能找不到，但是不知道如何处理 SQLException 。异常链可以用于抛出一 个更为合适的异常而不用丢弃关于底层失败的细节（例如栈跟踪），允许抽象层 将位于它们之上的分层同位于它们之下的分层的细节隔离开来，同时保留对于调 试可能有用的信息。 据说，诸如 JDBC 包的设计采取这样一种方式，使得它难以避免该问题。在 JDBC 接口中的每个方法都抛出 SQLException ，但是在访问一个数据库的过程 中可能会经历多种不同类型的问题，并且不同的方法可能易受不同错误模式的影 响。一个 SQLException 可能指示一个系统级问题（不能连接到数据库）、逻辑 问题（在结果集中没有更多的行）或者特定数据的问题（您刚才试图插入行的主 键已经存在或者违反实体完整性约束）。如果没有犯不可原谅的尝试分析消息正 文的过失，调用者是不可能区分这些不同类型的 SQLException 的。（ SQLException 的确支持用于获取数据库特定错误代码和 SQL 状态变量的方法， 但是在实践中这些很少用于区分不同的数据库错误条件。） 不稳定的方法签名 不稳定的方法签名问题是与前面的问题相关的 —— 如果您只是通过一个方 法传递异常，那么您不得不在每次改变方法的实现时改变它的方法签名，以及改 变调用该方法的所有代码。一旦类已经被部署到产品中，管理这些脆弱的方法签 名就变成一个昂贵的任务。然而，该问题本质上是没有遵循 Bloch 提出的第 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
