一个工作5年的程序员竟然可以这样说

shan_ghost

think1008 发表于 2013-12-07 22:15
断言应该没用吧，你发布版本难道也是DEBUG么？

断言的意思是：相关错误在测试阶段甚至进入测试阶段前就必须被排除，绝不允许带到发行版。

shan_ghost

Sevk 发表于 2013-12-06 13:37
有1百亿个数据等待处理， 其中10%的数据有2%的几率出异常，需要在生成数据的时候做判断。哈哈

一百亿个数据需要处理，不在源头把异常解决掉，反而要在之后的N流程中做N×一百亿次判断，哈哈

action08

回复 26# fender0107401


    当家的也别见外，这个社会一分钱一分货

koolcoy

1. void f1(void* p) {
   
2.     if (p) {
   
3.         func(p);
   
4.     }
   
5. }
   
6. 
   
7. void f2(void* p) {
   
8.     func(p);
   
9. }

复制代码

就鲁棒性而言，上面代码中的f1并不比f2高，因为野指针同样会照成f1崩溃，所以是否检查空指针完全看程序各个模块之间的约定。 如果cpu或者内存性能很重要，多余的针检查应该谨慎使用的。

koolcoy

1. void f1(void* p) {
   
2.     if (p) {
   
3.         func(p);
   
4.     }
   
5. }
   
6. 
   
7. void f2(void* p) {
   
8.     func(p);
   
9. }

复制代码

就鲁棒性而言，上面代码中的f1并不比f2高，因为野指针同样会照成f1崩溃，所以是否检查空指针完全看程序各个模块之间的约定。 如果cpu或者内存性能很重要，多余的针检查应该谨慎使用的。

yuccn

“
我把引起段错误的地方告诉了程序的作者，此人竟然说，这个指针应该不为空才对，现在指针为空说明了数据有问题，应该让数据的生产者去修改，他拒绝修改。
”

这个，对方做法也有他的理由，楼主应该明白，单单靠if (判断是否NULL)来避免出错，这样也不是就简单是完美的，因为这个本身就是调用者使用错误了，而不是被调用还输。
你看看strcpy之类的函数，你传个null进去看看？

如果你不服气，你可以看看这样的一个简单的例子
class test
{
     test_print() {printf("test")}
}

void func(test *p)
{
    if (p!=NULL) p->test_print();
}

你如果这样就能够避免错误了吗？加入传进来的p 不是NULL，而是一个非法的内存（造成非法内存的原因不少把），那么，崩溃点依然可能是在test：：test_print内部
那么你说这是被调用的函数的错误吗？

我只是想说明一个问题，你提到的确实是调用者使用错误而不是被调用函数。

当然可以理解你要求使用前判断一下的要求，不过这个不是解决问题的根本

工作十年的人也可以这样说的

kdkgod

我们做的服务程序，这个指针明明是没有new过的，这个可以确定，但是程序员还直接调用，导致程序崩溃，程序重启再崩溃，导致了服务不能用。

当然这个问题是双方面的，根本原因肯定是数据不全或者不对，但是如果程序不做容错处理的话那会导致后面的合法数据无法处理，后果是非常严重的！回复 36# yuccn


   

shan_ghost

kdkgod 发表于 2013-12-10 11:32
但是如果程序不做容错处理的话那会导致后面的合法数据无法处理，后果是非常严重的！

如果你做了“容错”然后把这个bug保留下来，而不是立即切实解决问题；那么，遇到非0的野指针就会把八杆子打不着地方的内存写的乱七八糟，后果是更加严重的。


而且，一旦出现后面这种情况，排错难度是非常大的，甚至近乎根本不可能。
于是你就只好做更多的“容错”，被写越界“陷害”的无辜模块就不得不搞更多检查、甚至因为检查/容错而搞出更多bug、甚至因为莫名其妙的错误而不得不瞎改、胡碰，期望“改了哪里错误就奇迹般的消失了”。

一旦搞成这样，这种糊涂蛋程序自然就更加无法分析了，只能加更多的“容错”；更多的容错更加重了程序的糊涂蛋指数……

最终，就是之前CU某牛的经典语录：一个bug，影响了7、8个模块，最后在一个毫不相干的地方爆了，你就慢慢查吧。
——当然，他是用来证明“容错”的必要性的。意思是毫不相干的地方也必须容错，否则“一个bug，影响了7、8个模块，最后在一个毫不相干的地方爆了，你就慢慢查吧”




而我的回答是：

这种情况，压根就不应该做“容错”，而是要在设计时就做好日志和恢复逻辑。

然后，发现任何不在设计考虑范围内的异常状况，就主动让程序马上崩掉。这就保证了崩掉时，内存是尽量干净的，而且bug几乎不会“影响了7、8个模块、然后才在一个不相关的地方崩溃”。这自然很容易就能找到bug并排除掉。

这种逻辑清晰、职责明确、不姑息错误的程序，才能真正做稳定。

而且，因为有日志、有恢复机制，那么很容易就能从日志恢复并继续处理“后面的合法数据”，并不会导致什么严重后果。

safedead

如果是我，我也会这么做，而且会更过分，我会用exit()代替abort()

uint64_t func(void *p) {
    if (NULL == p) exit(EXIT_FAILURE);
    do_somthing(p);//never check pointer 'p'
    return 0;
}

shan_ghost

打个比方吧，假如你的公司需要一家快递公司作为长期合作伙伴，那么如下两家公司，你选哪家？

A、超高容错，只要人活着，车就不能停！
制度：
1、我们的快递人员都是铁人三项冠军，马拉松运动爱好者：车辆抛锚了，推也能把您的货推到目的地！
2、我们的快递人员都经过严格的岗位培训，有F1赛事汽车维修经验；车内标配全套修理工具：随便车在哪坏了，他们都能在30分钟内修复！
3、我们的快递人员都有过硬的木工技术。车轴断了，砍根树枝，10分钟内就能替换！
4、所有人员经过严格政审，发现小偷小摸一律辞退，永不录用！


B、专业成就信誉，我们才不寄希望于斧子锤子板子
制度：
1、每一笔交易都有严格记录，随时随地追踪到人
2、繁华地区每30公里一个节点，偏远地区每100公里一个节点
3、每个节点随时有三辆车和三个司机备用
4、运货车辆从每个节点出发都要登记并通知下一节点；到达下一个节点的时间误差不得超过10分钟
5、车辆超过20分钟未到下一节点，该点的备用司机必须在5分钟内出车接应
6、所有车辆每运行1万公里或1个月，需由专业技师维护、并经严格测试合格后才能继续使用