诊断Java代码: 空标志错误模式 - 编程入门网

请注意：要使其余的代码能使用修改过的方法，我们还必须：

导入 java.util.NoSuchElementException 。

修正 hasNext ，使其不再调用 next 来进行测试。最简单的修正方法是只要直接调用 internal.readLine() 。

另一种处理 IOException 异常的方法是捕获它们，并代替它们抛出 RuntimeException 异常。决定这样做是基于对目标平台上预计 IOException 异常出现频率的估计。如果很频繁，那么您可能想试着从中恢复。

调用这个新 next 方法的任何代码可能都不得不处理抛出的 NoSuchElementException 异常。（当然，代码可以简单地选择忽略它们并允许程序异常终止。）如果这样，与原始代码抛出的 NullPointerException 异常相比，产生的错误消息和抛出异常的位置所提供的信息要丰富得多。如果抛出的异常是检查过的异常（比如 IOException ），那么它会更有用，因为除非处理了异常，否则类的客户代码将不编译。利用这种方法，我们甚至可以在程序运行前排除某些错误发生的可能性。但是，在这个示例中，不破坏 Iterator 接口，就不能抛出这样一个检查过的异常。因此，为了重复使用在 Iterators 上运行的代码，我们牺牲了一些静态检查。静态检查的目的和重复使用的目的之间的这种矛盾是很普遍的。

总结

在我完成这篇文章前，我要提醒许多经常使用空标志的程序员注意。许多程序员会争辩说这会使他们的程序更“健壮”。毕竟，他们可能会说，健壮的系统能够适当地处理不同的情况，而不是一遇到小问题就抛出异常。但是这种争辩忽视了这样一种事实，即异常是增强代码健壮性的有力工具，它允许在异常情况下控制能快速传送到最适合控制的位置。另一方面，空标志的使用把控制流限制在方法调用和返回的普通方式（当然，一直到整个程序崩溃）。此外，这样使用空标志，程序员有效地掩盖了异常情况出现位置的迹象。谁知道空指针在被丢弃前从方法到方法传递了多远？这只能使得诊断错误以及确定怎样修正它们更加困难。经验证明这种代码经常中断。我们首要关注的应该是避免这种困惑，使诊断尽可能容易。因此，作为准则，我努力编写可以尽快通知异常情况的代码，并且尝试着仅从没有指示程序错误的异常情况中恢复。

即使在代码中尽量避免使用空标志，您仍要不可避免地处理使用了空标志的旧代码。事实上，许多 Java 类库本身，比如我们上面使用过的 Hashtable 类和 BufferedReader 类都用了空标志。当使用这样的类时，您可以通过在执行前，显式检查操作是否将返回空来避免错误。例如，对于 Hashtables ，我总是在调用 get 之前用 containsKey 进行测试。但是，尽管采用这种预防手段，这种错误模式仍然是最常碰到的错误模式之一。

下面是本周的错误模式的小结：

模式：空标志

症状：使用空指针作为异常情况的标志的代码块报告 NullPointerException 异常。

起因：调用方法没有检查作为返回值的空指针。

治疗和预防措施：抛出异常来报告异常情况。

在下一篇文章中，我将讨论与类强制转换异常有关的错误模式。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!