暖魅的assert

    对于assert,用起来一直感觉很暖没,说起来assert能检查程序中的逻辑错误,但在发行版本中,这个检查又是无效或者说无用的(指望让最终客户通过警告解决bug?)。同时,我们也很难100%保证发行版的程序中,没有逻辑错误。一般来说,我们又不允许程序在发行版中死掉,哪怕错误的运行结果也好。于是很多时候我们的代码不得不看起来成了这个怪异的样子:

assert( sth_must_be_true );
if ( sth_must_be_true ) …
else  …

    如此一来,assert似乎完全是多于的东西。

    今天读云风《游戏之旅》,似乎对这个问题有了一些新的理解,感觉很不错。书中列举了两个错误的assert,分别是:

printf(“Are you sure ? (Y / N) ”);
scanf(“
% c”, & c);
assert(c 
==  ‘Y’  ||  c  ==  ‘N’);

以及某个游戏服务端使用assert判断封包是否正确的用法。

    第一例很明显,断言失败不可避免的发生在最终用户那里(是的,那个时候这句代码已经不存在了,但它还是发生了);而第二例中虽然这个断言有助与写出完美的客户端代码,但我们无法保证玩家不会模拟发出错误的封包,一个用户的错误封包就让一个网络服务程序崩溃显然是可怕的。也就是说,程序在实际环境下运行可能产生的错误,不能使用assert。而其它情况,如数组的越界等仅仅可能在开发阶段出现的问题,则建议使用assert让逻辑错误更早的暴露,更早的被解决,也就是所谓的“崩溃的程序不会说谎”。
    写到这里,问题似乎又回去了,现阶段,我们难以保证在开发阶段解决所有的错误,所以哪怕连简单的数组越界,我们仍然不得不在使用断言的同时做一个if / else 的判断以防止测试不充分带来的死机。当然了这样必然产生作者反复强调的效率问题,也许这就是书中所说的很无奈的情况吧。
 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值