检测Java代码: 破坏者数据错误模式 - 编程入门网

无论如何，数据都会以损坏的形式进入数据库，静静地等待被访问。如果用于访问数据的方法要求用逗号和空格来分隔条目，在读取这个条目的时候就会导致崩溃。

如果程序只是简单地使用逗号来区分集合中的元素，更加严重的错误都可能发生。系统可能将“pine birch”解释为一个单独的树类型（数据的单个条目），并将这个错误进一步传播到计算中去。

语义原因

我们的示例是一个违反了数据的一个简单的语法特征演示。当然，这不是可能损坏数据的唯一途径。

语义级别上的限定因素也可能被破坏。在我们的示例中，Mapping 表中数据的一种要求是，每个集合中的每个元素都是 Properties 表中的一个域条目。如果这种不变量被破坏，程序就会在试图读取一个在 Properties 表中并不存在的元素时失败，导致异常被抛出。

在本文中，我使用数据库条目作为示例，但是破坏者数据错误会以各种方式出现 ― 与数据输入的方式一样多。当程序读取数据时，不管它是从文件、键盘、麦克风、网络还是电子手套读取，破坏者数据错误都有可能存在。

治疗和预防措施

最好的防备破坏者数据错误的方法是编译器和解释器开发人员普遍采用的那种方法。由于输入到这些程序的数据是如此复杂，开发人员别无它法，只有在第一次读取输入内容的时候就执行尽可能彻底的完整性检查，而不是在以后访问的时候再进行检查。

语法分析作为消除错误的方法

实际上，对输入内容进行 语法分析的方法恰好是消除大量这些错误的途径。不幸的是，很多程序员（他们从来不会考虑编写没有语法分析器的编译器）没有能够为较简单的数据编写足够的语法分析方法。较简单的数据的语法分析当然要容易一点，但是这并不能成为根本不对它进行语法分析的借口。

任何读取数据的程序 ― 不管有多简单 ― 都应该对数据进行语法分析。毕竟，这种程序在它的有效输入的集合所定义的“语言”上可以被看作是一个编译器（或者解释器）。

从经历过的人那里吸取一点经验吧。我年轻时比较鲁莽，犯了个错误 ― 处理数据的时候没有作适当的语法分析，然后我就遭受了那样的后果 ― 猖獗的破坏者。我可不推荐这种经验。

类型检查作为消除错误的方法

编译器为许多语言（当然包括 Java 语言）所作的检查的另一种普遍形式是 类型检查。类型检查是程序完整性上的语义级别检查的一个示例。

如果类型系统是健壮的（就象 Java 类型系统一样），这种完整性检查确实可以保证很多错误永远不会在运行时产生。象语法分析一样，编译器编写者的这个示例可以应用于其它经常在其输入数据上规定语义级别不变量的程序。这些不变量通常不是明确的，但可以通过进行对应的检查来把它们变成明确的。

反复操作作为消除错误的方法

当然，如果您怀疑这种错误模式的出现与已经读入并存储的数据有关，反复操作数据也是明智的：访问在实际配置的应用程序中可能要操作的每个数据，保证一切都象期望的那样工作。通过这种方法，您也能够修正简单的错误。

关于消除错误方法的一个告诫

我的意思当然不是暗示执行足够的检查来消除程序中的所有破坏者数据 总是可行的。如果真是那样，就不会有引起错误模式的潜在问题了。

一个破坏者在开始带来灾难之前为什么会无法觉察是有很多原因的：

执行所有检查必需的数据直到破坏者数据已经存储了以后才可用。

整套的限定元素甚至是无法计算的（就象编译器和解释器的情况一样）。

限定元素可以计算，但是程序无法访问检查它们所需要的资源。

在这些情况下，我们最好是尽量消除可能的破坏者形式。

结论

下面是破坏者数据错误模式的总结：

模式：破坏者数据

症状：一个存储和处理复杂的输入数据的程序在执行任务时意外地崩溃，而这个任

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