用戶: 密碼:     忘記密碼 | 會員註冊
  

把握C++ Builder的調試藝術

8.2
出處:2345軟件大全 時間:2011-06-27 人氣:1473

核心提示:程序的bugs越少,最終用戶對這個程序的評價越高。而開發人員事先對bugs的處理越多

  以代碼為基礎的調試方法

  程序的bugs越少,最終用戶對這個程序的評價越高。而開發人員事先對bugs的處理越多,最終用戶能提供的關於bugs的信息就越多,也越準確,這樣,開發人員在接到最終用戶反映之後,就能夠快速找到出現bugs的那部分代碼,並以最快速度發佈程序的升級包。

  在這份教程中,我們從最基本的部合併始,逐步介紹許多在調試程序時“該當做”或“不該當做”的原則。正如你將看到的,這份教程中所指的“調試”這個詞所包括的意思很多,而不只是如大部分人所想到的--利用IDE集成的調試器的“調試”。我期望讀過這份教程之後,讀者可以在思路上有所收穫。

  寫易讀的代碼

  第一點,大概也是最重要的一點,就是寫潔淨易讀的代碼。易讀的代碼是很有價值的。請想像一下,假如隨便掃視一眼代碼或註釋,就能馬上知道這段代碼的的作用,以及在寫代碼的時候為什麼要這樣寫,當時的思路是什麼,那麼就可以節約大量時間。這樣的代碼,在寫的時候可能會稍稍慢一些,不過,當你調試程序時,就不會花上幾個小時來尋找bugs,相反,你可以快速,簡單的完成除錯工作。這時,你就會覺得多花一些時間使程序易讀是很值得的。

  所以,我推薦你在寫程序的時候,該當養成自己的風格,或是讀一讀Scott的關於代碼風格的文章。

  使用Exceptions和Exception的處理方法

  我們教程的下一步,仍然是以代碼為基礎的。因為除去一些少數的情況,開發人員不可能總是依靠於集成的調試工具。所以,學會用其它的方法來找到煩人的bugs是很重要的。一些重要的、處理的錯誤可能會在窗體之外發生。在C++標準制定出來之前的黑暗日子裡,在程序裡面發出發生錯誤的信號,通常是通過返回錯誤代碼完成的(現在這種方法仍然應用於OLE技術和一些Winapi函數),這樣的處理方法很輕易就會被忽略。(比如說,你經常反省winapi函數的返回值嗎?)所以,出現問題的可能性並不小。由於以上的原因,我們需要一個這樣的機制,它能讓我們不能忽略這些錯誤,而且,這個機制該當能被我們控制和自定義的。在這樣的需求下,異常處理機製出現了。需要一個非凡的錯誤類型嗎?簡單,定義一個新的異常類型就行了(和定義一個類的方法差不多),然後拋出(throw)它。下面這個例子說明了這一過程。

  例1:

    //----------------------------------------------------------------
class MyException
{
public:
AnsiString iMessage;
MyException(AnsiString Message) { iMessage=Message;}
};
throw new MyException(“Test Exception Message”);
//---------------------------------------------------------------

  就是它!(不是十分好,下面我們會繼續完善它)。簡單高效,而且便於自定義。或許你現在會問:“我可以使拋出異常了,但是,怎麼控制它們呢?我的意思是,我想在代碼的最前面排除異常。”C++Builder為我們中定義了try {} catch (...) {}機制。這和我們剛剛定義的異常機制的結構很相似。這個機制完全可以按照需要自定義。要使用異常處理了,只要把要執行的代碼放到try塊裡面,為了讓程序知道出現異常後該當做什麼,還需要定義一個catch()或是__finally塊。catch()語句裡面可以指定一個要捕捉的類型或是變量(比如例1,就是catch(MyException &E){ /* 異常處理代碼/}這個機制很強大,甚至可以用它來捕捉樹結構或是繼續類的異常,假如捕捉了基類的異常,它就能捕捉到繼續這個基類的所有的類的異常。比如,在VCL中,所有的異常都是繼續於Exception類。所以,catch(Exception& E)可以捕捉到除了EsocketError的所有VCL異常。(這點請非凡注重,當前還將繼續討論。)為了讓這個機制更強大,C++Builder中還定義了catch(…)語句。(沒錯,就是三個點)使用這條語句可以捕捉到所有的異常。還有更多的功能嗎?當然,你可以添加更多的catch()語句,可以向使用if...else if...語句那樣使用它。注重,在一系列的catch()語句中,錯誤不會被重複的捕捉,也就是說,假如前面的catch()語句捕捉到了錯誤,後面的catch()語句將不會捕捉這條錯誤。

  例2:

    //----------------------  
try
{
// 正常代碼
}
catch(EDBEngineError &E)
{
// 處理數據庫引擎錯誤
}
catch(EExternalError &E)
{
// 處理窗口類的錯誤
}
catch(Exception &E)
{
// 處理所有的VCL錯誤
}
//----------------------

  請看例2,它的代碼運行流程是這樣的:“錯誤是EDBEngineError嗎?是->處理它。不是->運行下一個catch語句”“錯誤是EExternalError嗎?是-〉處理它。不是-〉運行下一個catch語句”等等。

  這個機制還有更多的功能。假如你想處理異常,但是不想在處理的位置停止,那麼可以重新拋出異常。這時,程序將繼續尋找下一個catch()語句來處理這個異常。這個方法和“throw”差不多。這樣,你處理過的異常會再次被拋出,繼續尋找下一個catch語句來處理它。

  最後一個要說的是__finally(這不是標準的用法,是Borland添加的一個好方法),在__finally{}程序塊中代碼,無論是否發生異常都會被執行。這是一個清理程序中使用new分配的本地變量,設置用作旗標的變量值為正常的好位置。(比如,把一個等待狀態的光標圖標設置為正常光標。)

  就是這些了。有時間的話,請看看C++Builder幫助文件中的Exception類以及繼續Exception的類。這些將對於理解本節所說的內容有很大幫助。

  使用記錄機制

  你不可能總是用調試器來調試代碼,在某些情況下,可能無法使用內部集成的調試器,這時候,你就不得不依靠其他手腕調試程序了。(比如:Windows NT服務程序,ISAPI/CGI程序,實時應用程序等等)。這時候,有經驗的程序員可能會借助古老的調試方法,例如,使用一些分類的記錄機制來確定程序實際運行的過程。我們很幸運,現在有一系列的方法可以簡單的完成這樣的工作。下面將介紹3種我最喜歡的方法。

  第一個:OutputDebugString。(WinAPI: VOID OutputDebugString(LPCTSTR lpOutputString);)很幸運,微軟徹底的實現了調試子系統。它包括的一些特點可能讓你想把自己的記錄系統扔掉。應用程序在調試器進程中運行時OutputDebugString將用C字符串把調試器輸出的信息打印出來。假如程序沒有在調試器進程中運行,它將忽略這些調用。它會很好的在客戶的機器上運行,不會彈出信息窗口。假如在發佈給客戶的時候,忘記去掉這些代碼程序僅僅會變慢一點,不會有別的不良後果。

  第二個方法:使用了GExperts,通過 dbugint.pas接口進行調試。它是個可以稱之為偉大的程序,你可以把它分發給客戶。和OutputDebugString一樣,假如客戶沒有這個程序,它就根本什麼也不作。(它會主動檢測機器上是否安裝了客戶端)。要使用dbugintf,它很輕易被加入到你的工程中,加入#include "dbugintf.HPp"(要把它加入工程,然後會編譯它的pascal文件)。然後,你就可以直接使用SendDebug(要送到記錄文件的字符串); 或者,你需要它更機警一些,可以使用SendDebugEx(它給TMsgDlgType增加了一個新的消息類型)SendMethodEnter, SendMethodExit, SendSeparator等等(用法都差不多)。假如你打算給最終用戶分發客戶端 (Gdebug.exe),不要忘記include所需要的程序包。GExperts可以在http://www.gexperts.org 得到,它是收費的。

  第三個,大概是最艱苦的方法,就是使用你自己的記錄控制。這個方法可能不是你想像的這麼簡單。你可能首先會想到“在窗體上扔一個RichEdit,把它設置為只讀的,然後往裡面寫記錄”是這樣吧?理論上不錯,但是,實施起來...首先,使用RichEdit控件來做記錄,會大大降低應用程序的速度,還會在內存中造成碎片,甚至丟失內存。通常,在運行10分鐘左右之後,會使整個計算機的速度變慢!(這樣做簡直是在犯罪!)所以,假如你期望在自己的記錄中能夠使用彩色和圖標,那麼最好自己創建一個組件。假如沒有這麼高的要求,那麼有一個簡單有效的方法,就是使用ListBox控件作記錄,把ListBox的Style屬性設置為lbOwnerDrawFixed,這樣句柄將會自繪。(GExperts的控制台就是用這樣的方法製作的)。

  將記錄和異常處理結合使用

  你不用總是擔心可能會發生什麼偶然的異常。一般來說,通過很多的bugs測試後(盡量折磨程序,看看它會不會崩潰),應用程序在運行是該當不會出現什麼錯誤。下面的這個技術,建議組件開發者,在第一次把組件放在IDE環境測試的時候,很該當恪守。一個在IDE中產生的異常會導致很多問題,甚至可能無法重新啟動IDE也不能恢復。這個技術很簡單。在代碼中每一個函數或是主要的函數中加入:

    try
{
//函數的代碼
}
catch(Exception &E)
{
SendDebugMessage(“Exception caught in classname::functionname of type:” +E.ClassName()
+” with the message:”+E.Message);
};

  (把字符串中classname 和 functionname 替換成相應的類名和函數名。在出現錯誤時,你會馬上知道錯誤發生的位置。這樣也就不至於強制重起IDE的了。

  現在,讓我們看看前面的內容, ClassName()給了我們什麼樣的幫助呢?它只是用於返回字符串“Exception”嗎?每一次,E都被聲明為異常類型?這是VCL另一個優秀的地方,所有的類都從TObject繼續,所以,這些類都能主動獲得正確的類型和基類的類型,所有的更多的信息都可以在這裡找到。(請參見TObject的幫助)所以,儘管我們使用了Exception &E,其中的E.ClassName()將返回捕捉到的產生異常的實際類名。得到這些好處需要付出的代價是編譯出來的可執行文件變大了一些。所有的Delphi/CBuilder用戶都注重到了這一點,但是他們說,沒有付出就沒有收穫。其中,他提到了使用TStringList作記錄的方法:先將錯誤通過TStringList的Add方法加入到StringList裡面,然後使用SaveToFile保存到硬盤上。不過要注重在程序結束的時候不要忘記使用SaveToFile()方法把TStringList保存起來。或者,也可以每次捕捉到異常之後都保存一次。

  在代碼外部進行異常處理

  這是使用代碼處理異常的最後一節,當前,我們將使用IDE的調試工具。但是,這節中講到的方法在處理致命錯誤時是很重要的。比如說:可以顯示一個包括了錯誤信息的對話框,這樣,用戶報告bugs的時候會清除的多。你肯定不想聽到用戶報告說:“啊,這有個對話框,上面寫著什麼地址發生了錯誤”。有個好辦法能改善這種狀況,請往下面看。

  第一步:在主窗體(工程設置裡面,主動創建的第一個窗體)中創建這樣一個函數:

    void __fastcall AppLevelExceptionHandler(TObject *Sender, Exception *E)
{
}


然後,在裡面加上顯是錯誤(E->Message)的代碼,錯誤類型(記住前面提到過的E.ClassName())以及其他需要的細節信息。

  第二步:把它與系統掛鉤。很簡單,只需要在窗體的OnCreate事件中加入這行:

  Application->OnException=AppLevelExceptionHandler;

  在這行代碼上,不要吝嗇,因為加上它,基本上就可以說所有的錯誤都不會漏掉了。無論在任何地方發生的錯誤都可以被捕捉到。

  現在,所有以代碼為基礎的調試方法你都學會了,馬上把他們加入到你的工程裡去吧。最好能把它們變為你的習慣。這將對你的程序有很大幫助。