第34章 辭職前

    但到了後面，他們仍然習慣性的用了“正常”的命名，也可能是選錯了編輯器自動提示選項。

    這就相當於丟開局部變量，用了命名空間的外部變量；但從上下文看，這裡就不應該碰外部那個同名變量。

    用偽碼錶示大概是這樣:

    class oneclass {

    packagenameitems = null;

    ....

    void funname1(arg){

    //initial packagenameitems

    packagenameitems = arg;

    //other...

    }

    string funname2(){

    packagenameitems = extractpureinfo(packagenameitems);

    //do sth

    ....

    result = getitemfrom(packagenameitems， itemname)//1

    //do sth

    ....

    return result

    }

    }

    從那裡分析，在//1處，本應該是從已經解包過的packagenameitems中，取它的第n項；但這裡誤傳入瞭解包前的packagenameitems。

    似乎輸入文本可能會發生幾種情況，當然多數情況不需要進一步處理，直接用外部那個變量就行，此時兩個變量內容一致，不會觸發bug；但少數情況下，外部那個變量需要進一步處理，這才能提取到正確的內容。

    這種情況下，兩個變量內容不同，誤用了前一個變量就讀不到正確數據了。

    這是個極為隱蔽的邏輯錯誤。

    其實和變量作用域相關的故障都很隱蔽。

    李明拿著整個調用鏈的詳細記錄，也是看了好幾遍才發覺這兩個變量的名字似乎有些意思，這才沿著這條線追查下去……

    總之，意外的輸出信息弄得他們一臉懵逼，因為這時候根本就不應該有這種信息，也幸好檢查條件設的比較窄，只有正常返回可通過，其他一概拋異常崩掉——於是這個異常就被葉新晨的debug工具抓到，自動記錄了調用棧信息。

    所以說為什麼之前錢志海等幾人會驚訝，因為這個功能給他們抓到了一個bug。

    還好這是個極為簡單的bug，只需把最後那次訪問時，首字符小寫的變量名改成大寫，故障就不再復發。

    其實就這麼簡單個首字符大小寫搞錯、誤訪問了外部變量的bug，羽然科技公司在黑土平臺上的懸賞單也是掛了有兩三年了，前前後後換了很多人經手，但就是沒人能抓到它。