你防御了吗？
荣耀 2002
Andrew koenig先生的《C陷阱与缺陷》（高巍 译）一书中，有这样一段关于“防御性编程”的文字：
对程序用户和编译器实现不要作太多的假设！我还记得自己在开发某个系统时，曾经与一个用户有过这样一场对话：
“这部分记录中可能出现的代码有哪些？”
“可能的代码是X、Y和Z。”
“如果与X、Y和Z不同的代码在这里出现了，该怎么办呢？”
“这不可能发生。”
“嗯，但如果这种情况确实发生时，程序需要做些适当的处理。你认为程序应该做些什么呢？”
“这个我可不关心。”
“你真的不关心？”
“对。”
“那么，如果程序在检测到不同于X、Y和Z的代码出现时，删除整个数据库，你也不会介意吗？”
“太荒唐了。你绝对不能删除整个数据库！”
“那就是说，你还是介意程序在这种情况下的行为。那么，你希望程序做些什么呢？”
我们知道，再怎么不可能发生的事情，某些时候还是有可能发生的。一个健壮的程序应该预先考虑到这种异常情况。
（说明：以上文字和中文图书对应文字略有出入）
这并非是我第一次接触“防御性编程”思想，甚至14年前它就不是Andrew先生的首创，但这段话很对我的口味—听起来极端，却无可辩驳。
两年前，我曾写过一个程序，可以根据用户喜好，将SQL语句执行结果以多种方式显示出来。这个程序一直运行得很好，直到有一天一位工程人员向我抱怨，他无法将一条超长SQL语句存放到数据库中。
这真使我惊讶！我从来都没想到有人会写出一条超过4000个字符的SQL语句。后来我把这个字段类型改成了BLOB。
现在，程序员甲写了一段A程序，程序员乙写了一段B程序。B程序具有用户界面，接受用户输入，并将输入存放于数据库中，A程序则解析和使用这些数据。
有一天，A程序突然崩掉了。经过检查发现，由于乙疏忽编写有效性验证代码，导致用户可以从B程序界面上，录入A程序始料未及的非法数据。正是这些非法数据，导致了A程序的崩溃。
毋庸置疑，乙的B程序需要改进，但甲的A程序呢？嘿，Mr.甲，你防御了吗？
在“定义性数据”的输入口，我们就应该重视数据的合法性验证问题，但不到被解析和使用时，“定义性数据”不会造成任何后果，“定义性数据”的来源也可能五花八门（比如直接写数据库而得），因此，“防御”就成了“解析和执行模块”不折不扣的责任。
－完－
