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

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

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

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

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

例1：
[code cpp]
//----------------------------------------------------------------
class MyException
{
public:
AnsiString iMessage;
MyException(AnsiString Message) { iMessage=Message;}
};
throw new MyException(「Test Exception Message」);
//---------------------------------------------------------------
[/code]
就是它！（不是十分好，下面我們會繼續完善它）。簡單高效，而且便於自定義。也許你現在會問：「我可以使拋出異常了，但是，怎麼控制它們呢？我的意思是，我想在代碼的最前面排除異常。」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：
[code cpp]
//----------------------
try
{
// 正常代碼
}
catch(EDBEngineError &E)
{
// 處理數據庫引擎錯誤
}
catch(EExternalError &E)
{
// 處理窗口類的錯誤
}
catch(Exception &E)
{
// 處理所有的VCL錯誤
}
//----------------------
[/code]
請看例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也不能恢復。這個技術很簡單。在代碼中每一個函數或是主要的函數中加入：
[code cpp]
try
{
//函數的代碼
}
catch(Exception &E)
{
SendDebugMessage(「Exception caught in classname::functionname of type:」 E.ClassName()
」 with the message:」 E.Message);
};
[/code]
（把字符串中classname 和 functionname 替換成相應的類名和函數名。在出現錯誤時，你會立刻知道錯誤發生的位置。這樣也就不至於強制重起IDE的了。

現在，讓我們看看前面的內容， ClassName()給了我們什麼樣的幫助呢？它只是用於返回字符串「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的時候會清除的多。你肯定不想聽到用戶報告說：「啊,這有個對話框，上面寫著什麼地址發生了錯誤」。有個好辦法能改善這種狀況，請往下面看。

第一步：在主窗體（工程設置裡面，自動創建的第一個窗體）中創建這樣一個函數:
[code cpp]
void __fastcall AppLevelExceptionHandler(TObject *Sender, Exception *E)
{

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

第二步：把它與系統掛鉤。很簡單，只需要在窗體的OnCreate事件中加入這行：
[code cpp]
Application->OnException=AppLevelExceptionHandler;
[/code]
在這行代碼上，不要吝嗇，因為加上它，基本上就可以說所有的錯誤都不會漏掉了。無論在任何地方發生的錯誤都可以被捕捉到。

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

來源：tech.china.com 作者：未知
轉貼網址:http://icgle.net/Technic/technic/2007/5/22/Technic11463.htm

不錯，先收藏起來了，雖然我大部份是用  Delphi ，不過觀念應該是通的

------
價值的展現，來自於你用哪一個角度來看待它!!

呵呵，畢竟師出同門啊，絕大部份用的語法是相同的(只有codegear自創的才是)
Delphi的資料好多，我想也應該多學一點delphi了(笑)

===================引 用 careychen 文 章===================
不錯，先收藏起來了，雖然我大部份是用 Delphi ，不過觀念應該是通的

不錯的咪呀
先收下哩
謝拉...

------
ΞΛΤ造福全人類ΠΔζ

不錯，先收藏，謝謝！

首先謝謝大大花時間寫出這篇文章
真的.這真是篇好文章
以個人寫程式的經驗
詳細的除錯訊息
確能提供爾後程碼賡修的好依據
good啦

------
Oo吉米oO