程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> C++ >> 關於C++ >> 掌握CB的調試藝術

掌握CB的調試藝術

編輯:關於C++

程序的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()給了我們什麼樣的幫助呢克皇怯糜诜禱刈址?ldquo;Exception”嗎?每一次,E都被聲明為異常類型?這是VCL另一個優秀的地方,所有的類都從Tobject繼承,所以,這些類都能自動獲得正確的類型和基類的類型,所有的更多的信息都可以在這裡找到。(請參見Tobject的幫助)所以,盡管我們使用了Exception &E,其中的E.ClassName()將返回捕獲到的產生異常的實際類名。得到這些好處需要付出的代價是編譯出來的可執行文件變大了一些。所有的Delphi/Cbuilder用戶都注意到了這一點,但是他們說,沒有付出就沒有收獲。在http://www.bytamin-c.com/的howto欄目可以看到Xiphias的一系列文章。其中,他提到了使用TStringList作記錄的方法:先將錯誤通過TStringList的Add方法加入到StringList裡面,然後使用SaveToFile保存到硬盤上。不過要注意在程序結束的時候不要忘記使用SaveToFile()方法把TStringList保存起來。或者,也可以每次捕捉到異常之後都保存一次。

在代碼外部進行異常處理

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

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

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

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

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

Application->OnException=AppLevelExceptionHandler;

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

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

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved