都知道发烧不是因为额头被热水烫过,肚子疼通常也不会是因为肚子受伤.其实调程序也是如此.
找错误的时候不该只从错误的地方区找,有可能在遥远的地方的问题,导致了这里的错误.
也不要去相信那些从来没出过错的地方,就是不会错的,从来不错只表示它过去没错,不表示现在也是对的.
今天一个同事的程序就遇到这个问题,一个自定义表格控件,用了很久了,突然今天发现在一个窗体上操作着操作着就绑不出来数据.
重新进入窗体又可以了,郁闷了很久,单步调试了几个小时(因为不知道怎么重现这个错误,反正就是"某些操作"以后会错),把所有的
代码逻辑都过了好多次,可是就是找不出错在哪,只知道就是在某些地方经过以后,就再也不可能出来数据了.
晚上没辙了,明天要用的,就这个地方过不去,于是扔给我帮忙. 我重复操作几次,掌握到大致的出错地方,然后就在重点区域,如绑定操作
的附近设了断点,运行了几次次,发现代码没有错,Sql语句返回正确,表格绑定方法也没有问题,返回true,就是数据再也不出来.
观察到表格的脚部对数据的条数统计是正确的,只是上面不显示数据. 监视了表格控件的一些主要的属性,意外地发现,表格中表示
当前页索引的属性值是-1,显然这是问题所在,搜索了一下,发现窗体中没有对这个属性赋值的操作.那-1又是怎么来的? 重新进入窗体
属性值出现正确的0,然后做会改变这个值的操作(翻页,在表格组件内部实现) 发现都正常,然后再尝试那些有可能产生错误的操作,
试了好几次,终于有一个地方,操作以后变成了-1,-1以后就永远-1了. 当一个操作导致表格中没有数据的时候,表格的页索引就变成-1
脑海中马上明白发生了什么事了,bug在表格控件内部. 马上也猜出产生这个错误的原因. 原来表格本身保持了这个属性的状态,这样
在多次绑定数据的时候,如果第一次绑定了N页,第二次绑定了M页(N>M+1),并且在第一次绑定以后,翻到了第P页(N>P>M),那么在第2次
绑定的时候这个状态依然是P,而实际上数据却并没有那么多,会抛出NullReferenceException的异常,于是猜测表格控件的设计者考虑到这个情况,
于是,对此做了处理,当遇到这个情况时强制令 P=M-1 (因为一个索引是0开始,一个是1开始,所以-1). 但是他却忽略了同时M=0的情况.
在M=0的时候,P就出现了-1 .由于这个第-1页是没有意义的,也是原控件设计者所没有考虑到的情况. 就发生了上述那些奇怪的总数
统计正常,而数据不显示(因为根本不存在第-1页的数据),由于上面没有数据,又引起了翻页功能的不可用,因此也不可能把这个-1
给修改回来,于是就不管怎么绑数据,怎么操作,都一直-1下去了...
反编译了原控件,从IL中证实了我的猜测完全和实际情况一致. 于是解决问题就变成非常简单了.
另外有一点,控件中对一些异常,有必要throw出来给外面一层,虽然说如果外面没有处理会造成程序崩溃,但是要是把所有没有意料到
的异常都用一个空的catch块把它杀死在控件内部,其实更加危险,造成程序的不可预料性,而且又难以查找.所以这里有一个平衡的问题.
这还是看设计者的经验,具体问题具体分析.
