大家在项目代码中会大量使用断言么？

77h2_eleven

这个投票只因为看《编程精粹》中，建议项目大量使用断言。
但是我们的项目都是采用条件判断+异常保护+日志。没有用过，惭愧。

cuinantrue

原帖由 shan_ghost 于 2008-12-18 10:48 发表



http://bbs.chinaunix.net/viewthr ... =9806331&page=2

看看，我说要随时提高警惕吧。

问楼上一句： 这种行为，是不是跟着那个偷偷跑僻静处拿针扎纸人的太监学的？

提什么警惕啊，就一个论坛，几个人问几个问题，犯的上骂完这个骂那个吗，一个大男人，为了这么点事情破口大骂，骂完了还不许别人说话，谁说骂谁，CU怎么了这是？

shan_ghost

原帖由 cuinantrue 于 2008-12-16 17:30 发表


此人对编码着实有些研究，只是让我想起一个人，祢衡。

http://bbs.chinaunix.net/viewthr ... =9806331&page=2

看看，我说要随时提高警惕吧。

问楼上一句： 这种行为，是不是跟着那个偷偷跑僻静处拿针扎纸人的太监学的？

cuinantrue

原帖由 shan_ghost 于 2008-7-6 16:31 发表
是的。逻辑错误难以避免，软件bug层出不穷，没有人能保证它永不出现。

但是，如果有办法可以辅助捕捉到——甚至于，如果有确凿的迹象（比如strcpy得到了空指针）可以证实——逻辑错误的存在，我们是不是应该 ...

此人对编码着实有些研究，只是让我想起一个人，祢衡。

[ 本帖最后由 cuinantrue 于 2008-12-16 17:33 编辑 ]

vktri

断言该用时还得用

nhuczp

我样要求，特别是写日志等！！

sunnyfun

除了那些极端的发现异常就需要crash的程序外，
使用断言的最大用途还是自动化测试吧，编写好测试用例和预想结果，并存档，当代码优化或重构后跑一下，以验证新的程序和旧的程序在行为上没有改变。

没本

断言在很多地方不适用，比如我是不用的

shan_ghost

呵呵，在另外那个帖子中讨论时还针对神七飞船写了个案例，不过感觉前面的帖子已经说清楚了，就没有发。

大家在学校学的东西，往往都是一些局部的、分离的算法，很少有站在大局角度通盘考虑的；并且国内教授自己多数也没什么实践经验，教不好错误处理很正常。


案例：

神七飞船载重有限，因此减速火箭只能在着陆前5秒打开（因为燃料就这么多）；实际上，这个数据考虑了最不利状态下姿态控制的需要并留有1秒的余量。

现在，要求是设计一个能保证安全着陆的程序。
这个程序要读取飞船当前的姿态、速率以及高度、风向、风速等信息，然后实时控制飞船着陆。


现在，考虑这样一种情形： 假如上级调度模块在宇宙空间的恶劣环境下，因射线击中存储器某单元造成状态翻转，致使栈写越界——于是着陆控制模块发现，指向飞船姿态数据区的指针被改写成0了。

当然，这种情况是无法事先预估到的。怎么办？


如果返回错误码，是可以避免因引用无效内存而崩溃；但被破坏的栈可不会自动恢复。
很可能，这个return指令会因为栈中返回地址也已经被破坏，而使得代码跳到一个未知的位置继续执行——也许飞船都撞到地面了，这段跑飞的代码还没回来；减速火箭自然也就不可能打开。

于是，飞船撞毁，宇航员必死无疑。



正确的做法只能是——发现异常就crash！

PS：介绍个新概念：watch-dog（搞嵌入式的应该很熟悉这个）。
——watch-dog的原理就是：要求程序必须安排合适逻辑定时清零计数器（报告状态正常）；一旦计数器到时没有清零，就立即reset系统（相当于crash）。因为此时程序可能已经跑飞了（当然，也可能是时序没算对）。
——当然，watch-dog的周期不可能太短，否则对系统性能消耗过大；但太长又可能导致反应不够灵敏，这是必须根据实际折中考虑的。

实时系统的重启速度相当快。玩数码相机的应该有所体会——我的那个好像说是0.0x秒吧。

于是，由于设计上预留的1秒缓冲，若能立即crash的话，系统可以容忍连续10次失败仍能保证飞船安全着陆——连续2次或3次失败后自动切换备用系统等等设计也才有了发挥空间。

可见，crash不是洪水猛兽。它是构建真正稳定的系统的不可缺少的一环（当然，普通如word等软件，出错直接崩溃提交就行了，没必要设计机制保障7*24的绝对安全性）。


相反，如果仅仅返回个稀里糊涂的错误码，系统跑飞被watch-dog抓到还算好（但也已经耽误不少时间了），万一跑飞的那个地方刚好是刷新watch-dog的逻辑，岂不完蛋？

搞出这种飞机的，有几个脑袋够M249打眼？

——————————————————

说到底，这纯粹是个态度问题。

都知道捕获所有异常并忽略是完完全全的混蛋；但每个错误都要查清来龙去脉却也不是易事——尤其是在缺乏责任心的人那里。

所以，“聪明”人就有了发挥其“中国式智慧”的机会了：有错，我知道，我也报告了——别人不处理怪他。
别人？
别人也不是傻蛋。你报告我也报告，说不定问题绕了一圈又回你手里了。
——无所谓，反正程序还能跑。

最后，代码中充斥着各种各样稀奇古怪的错误，到处都是错误码，人人都在写日志——反正正常流程能走通，交得了差。

你说什么？空指针不准确确定原因和影响范围，稀里糊涂返回错误码可能导致程序跑飞？
跑飞就跑飞。又没崩溃。
反正到处都是检查，到处都是容错，说不定飞着飞着它就又飞回来了——像蟑螂一样，这系统命硬着呢。

你说这样说不定哪天就撞到格硬盘刷bios的那块代码了？
没事，那才多大点概率。我可以保证99%，至少也有90%的情况下跑不到那里。

总之，不崩溃才是王道——很明显，这种容错容的跑飞说不定还能跑回来的系统，你哪里知道崩溃时已经跑飞多少遍了！

一旦崩溃——苍天啊！这问题谁有本事定位！！

说不得，整个系统大返工，每个函数每个参数的——不是查故障啦，没法查——加容错代码。
——口号是：一定要保证程序跑飞后还能跑回来!
（当然，这时候逻辑是否正确、数据有无丢失就顾不得了）

显然，随着程序的崩溃，搞出这种垃圾的程序员怎么可能不恐惧到崩溃。
——我理解这种病人；但不认为他们值得同情。




一言以蔽之：一群没责任心的懒蛋想偷懒，结果越偷懒越是忙得不可开交；最终代码写了5000行，其中容错逻辑倒有3000多行——其中1800行是为了给那2000行代码加容错逻辑；另外800行是给1800行容错代码加的容错；剩下的则是容错代码的容错的容错（的容错……）。

越容越复杂，错也就越多；错越多越无计可施，只能继续容错，于是系统就更复杂更不可调试……

——————————————
assert的思想本质就是： 出错了，一定要立刻崩溃（报告），千万别拖来拖去搞出先跑飞再崩溃的飞机。
只有这样，排错才会轻松惬意——跑一跑，根据assert报的行号直接过去修改问题就是，几乎不需要什么代价。
assert越多、越准确，错误就被限制得越死；一旦触发到，问题也就越好解决。

至于发行版assert自动失效（这已经是内建于c/c++标准库的机制了），原因仅仅是不希望为无用的东西付出运行时效率而已（无用二字正体现了对测试流程的自信，同时也显示出这种系统有多好测）。
——这种境界，显然不是没这样做过的人所能理解的。

cuur2008

用断言是为排除发布之前的BUG。