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

shan_ghost

是否精确识别错误类型，以明确逻辑处理不可抗拒问题、以严厉态度对待编码逻辑类问题，不给它改头换面的机会，是识别面条代码的关键。

benjiam

原帖由 shan_ghost 于 2008-7-2 09:55 发表
只能说阁下根本没看懂我在说什么。


apache测试了什么？
它测试的是真正的、不可预知的异常：
  if (!fname) {
        /* Reinitializing unnamed mutexes is a noop in the Unix code. */
        re ...

return FAILED;         /*  返回表示错误的值 */

它有错误返回好不好， 无论是否是调用的错误。所以你可以按照返回的结果进行操作。


只要你认真做了单元测试，那么不可能触发不到它；如果真没有触发到，其他的办法同样不能解决问题，同样要在最终用户那里爆炸

int
    string_copy3(char* dest, const char* source)
    {
      if (dest != NULL && source != NULL) {

这里才是做了检查。

只要你认真做了单元测试，那么不可能触发不到它.
微软的代码 我相信都是经过了单元测试的， 而且至少是 pc-lint 静态检验的。但仍然不时的崩溃。 这说明了什么？ 问题比你想的要严重。

我认为
至少在每一环都要处理好。 如果我返回的错误，无法得到调用者的注意，那么我也就无能为了。 至于用什么策略对待返回的结果，我认为这才是水平，写得不好 就是一拖一拖的。
你认为 如果红灯亮了，还有车子不停 就直接摧毁它，也是一种好的方法，那么你就继续做吧。

shan_ghost

还是一塌糊涂^_^

没有说不能返回错误，相反，我一直在强调要“以明确逻辑处理不可抗拒问题”。

说的明确点，就是： 要在设计时为不可预料的情况做好准备。

如果看过我写的代码，你会发现我返回的错误更多、种类更细；甚至同样种类的错误，我都还希望能够区分它们发生地点的不同，传递出足够的细节。




但是，另外一些情况是 不应该 捕获的。如果它们要炸，就让它们炸掉好了。

比如，strcpy空指针这样的问题。
非常明显，一个空指针被传到这种函数里，这绝对是一个不可原谅的逻辑错误。这甚至可能意味着程序结构需要重新设计。


每一环都要处理好这句话太含糊。

如果strcpy发现空指针就炸掉，上层调用者会怎么做？
1、catch所有异常，报错；
2、修正自己的逻辑，防止出现非法调用。

他有没有处理好，一目了然。


相反，如果strcpy不炸掉，这就相当于一个隐式的catch all；不仔细分析你还找不到。

好一个大事化小，小事化了的中国式“智慧”！


你觉得哪个strcpy才算把自己的那一环处理好了？
是发现漏洞就毫不客气的揭发、逼上层调用者catch以至于欲盖弥彰那个；还是发现漏洞主动降级，大事化小小事化了那个？



微软的东西是喜欢崩溃；但如果他们也搞个catch all，让你从此永远见不到错误报告，是不是就真的“稳定”了？

中国电信的系统比起微软的显然“强壮”多了，怎么都不会崩溃，只是偶尔出点小错而已。

你觉得哪家的软件质量高？

77h2_eleven

原帖由 shan_ghost 于 2008-7-2 11:17 发表
中国电信的系统比起微软的显然“强壮”多了，怎么都不会崩溃，只是偶尔出点小错而已。

个人觉得是一种态度问题。
微软之所以推荐大量使用断言。就是想在问题发生后，让程序员“不得不”解决这个问题。
当然《编程精粹》的作者也同意大家可以自己定义断言，可以在异常发生时不用终止程序。
就个人来说，我是比较具有惰性的。
例如：
    我接手了前辈的大量代码，如果发现日志里面有个小报错，但是子程序做了保护，就是说没有对系统的功能造成影响。一般的话，就很少会下定决心去分析这个问题。
    但如果程序终止了。我就“不得不”去查那些代码了~~~~~~

benjiam

没有说不能返回错误，相反，我一直在强调要“以明确逻辑处理不可抗拒问题”。

说的明确点，就是： 要在设计时为不可预料的情况做好准备。

如果看过我写的代码，你会发现我返回的错误更多、种类更细；甚至同样种类的错误，我都还希望能够区分它们发生地点的不同，传递出足够的细节。

这就够了。  你可以抛异常出去， 调用者看都不看。
或者你的代码是c 的，没有异常这档子事。 返回值出去 调用者页不管，那么我们就无能为力了。
剩下的事情不是我们能解决的。


要在设计时为不可预料的情况做好准备。 如果逻辑错误不算是可以预料的错误的话，请自便

如果strcpy发现空指针就炸掉，上层调用者会怎么做？
1、catch所有异常，报错；
2、修正自己的逻辑，防止出现非法调用。

如果有个逻辑错误，偶尔的发生， 影响到了3-5格模块的内容， 其他的逻辑错误都是返回错误。但是没有的异常错误， 最后在strcpy 里面爆发了。你想定位就慢慢花时间吧。

其实此时，将返回结果记录成为日志是最快的定位错误的办法。

你把 3改写成 你的面试结果，让我们看看吧。 c code.

shan_ghost

这正说明您的那几个模块就是传说中面条

见我第二页的帖子：

这种面条代码，说穿了就是一种“踢皮球”游戏： 发生错误了，没有人知道错误究竟在哪里，也不知道错误处理路径是什么；但无论如何，这个错误不能在我手里炸掉。
于是，错误就以一种“击鼓传花”——错，传炸弹——的方式四处流窜，就看爆在哪个倒霉蛋的手里了。
总而言之，爆给谁，谁挂这个问题单，背这个黑锅就是。



兄弟，在下为你默哀～～

在这种面条公司做面条项目，除了把自己的代码也写成面条外，别无它法。

不过，入鲍鱼之肆，久而不知其臭。望阁下珍惜自己的大好前程。

benjiam

这种面条代码，说穿了就是一种“踢皮球”游戏： 发生错误了，没有人知道错误究竟在哪里，也不知道错误处理路径是什么；但无论如何，这个错误不能在我手里炸掉。

第一个接皮球的人 就该处理，他不处理 错误就会扩散。这是显而易见的事情。如果他不处理造成了问题源头自然在他。这其实是一个路径覆盖问题，而不是什么面条问题
而如何处理，如何将运行流程处理好是难度， 处理得不好 那就会象瀑布一样 流得到处都是。那时候 就是几百个分流 处理起来就真的要命了。  这才是面条问题。  在处理流程的时候，有些问题要急时的掐断它，否则 它会弄出很多分流，擦起屁股就很困难了。


我等你代码呢。

yuanchuang

需要耗性能的判断，用assert，比如dynamic_cast
还有产生某个程序必须退出的错误，也用assert
否则用我自己写的简单的错误判断宏

shan_ghost

讲个小故事娱乐一下吧。


话说 microhard、某个做freeware的菜鸟、另一个做freeware的老鸟 还有 xx面业集团有限公司同时进入字处理软件领域展开了激烈的竞争。


为了争夺用户，他们都为自己的软件增加了正则表达式查找功能；但由于某个unicode特殊字符的原因，他们的某个内部辅助函数都出现了空指针……


microhard的做法是： 此函数因空指针而崩溃；异常无法得到合适处理，软件崩溃了；一个窗口自动跳出，帮用户自动提交了此时的栈数据。

做freeware的菜鸟的做法是： 此函数因空指针而崩溃；异常无法得到合适处理；但这个菜鸟学习很努力，知道要尽可能“优雅地退出”。程序保存了用户数据，退出了。

做freeware的老鸟的做法是：此函数因空指针而崩溃；异常无法得到合适处理；但由于漂亮的模块划分，老鸟知道是find出了某种未知问题。于是提示用户重新搜索（当然会再次出错）。连续几次后，程序自动弹出一个表单，要求用户填写他都干了什么，然后自动提交。

而xx面业集团有限公司的做法是： 此函数发现了空指针（他没有用像以上三位一样用assert），返回arg error；但上层也不知道该怎么办，错误就这样被一层层向上传递着，同时又被扭曲着（从原始的null->arg error->xxx error->yyy error->zzz fault。。。）；直到某个设计只能返回true或false函数，被归一为false返回——问题就这样莫名其妙的消失了；他们的程序理所当然的告诉用户“你要找的东西没有找到”。


最后：
microhard的软件最容易崩溃，补丁最多，但用户也最多。（用户：虽然它不稳定，但用起来就是顺手！）

freeware菜鸟的软件虽然看似比microhard稳定，但更新太慢；大量的bug一直赖着不改（其实是因为他不知道）。

freeware老鸟的软件最好，最稳定，更新也快，深受专业用户的喜爱；但所有用户都认为那不是一般人能用的——比如发生错误后那个吓人的考卷。

至于xx面业集团公司的软件，它简直稳定极了，而且一直都没什么bug被发现；但用户总觉得它什么都做不了（记者：请给xx面业集团公司的软件一个评价。 用户：这是个面子工程。他们就是做了几个窗口放在那里，只要看起来像，上级就会给他们拨款。老实说，这玩意儿我也会做【镜头：用户打开VB，正在窗口中放置控件……】）。

flw

支持 shan_ghost 的观点。因为这是一种从全局出发考虑的观点。