关键字 防御性编程 *沉思录：你“防御”了吗？ * 荣耀 2003 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.甲，你“防御”了吗？ －完－ # 作者相关文章： 沉思录：别人的棺材(原作) # C++设计日志：读写定界符文件(原作) # 软件就是服务？？(转贴) 对该文的评论 ooing/(2003-1-17 12:55:07)/ 我觉得不是非得叫你去检查从接口处获得的信息的正确与否 而是你的程序必须有个完整的出错处理 这样 对一些不可预测的情况才可以扼杀在萌芽状态 jiangchun_xn/(2003-1-17 12:30:57)/ 大家看微软很多的“代码”，我想每个函数中无数的assert大家习以为常了吧/哈 哈。我曾经写过程序去掉所有的assert来阅读的：（。其实在实际应用中，每个单 独的UNIT都应该作好防范。微软一位大牛（名字忘了，反正挺牛）写的一本老书- 编写优质无错C语言代码，中，就强调了这一点。。我觉得很对 ajoo/(2003-1-16 9:58:23)/ 那么怎么个防御呢？是以人为单位吗？ 一个程序员对另一个程序员的输入一定要检察错误？自己的模块之间就不检查？万 一，明天两个程序员要接手你的工作，他们两个还得往程序里加检查错误代码？ 还是，每一个函数里都检查错误？ 象这样： void f(int x){检查x; f1(x);} void f1(int x){检查x; f2(x);} void f2(int x){检查x; f3(x);} ...... 不现实吧？ 其实，软件设计就是一个责任的分工。谁负责什么都要很清楚。数据验证也一样， 谁负责验证什么都应该搞清楚。大锅饭好像不是什么好办法。至于出了问题，那是 测试没搞好，你怪甲干什么？要说怪，应该怪project leader. 他没有把责任分清 楚，也没有把好测试关。 当然，甲应该设计他的接口使得调用者不那么容易犯错误，如，充分利用语言的类 型系统。但是，到处重复同样的检测逻辑明显是错误的。