程序的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;
在這行代碼上，不要吝啬，因為加上它，基本上就可以說所有的錯誤都不會漏掉了。無論在任何地方發生的錯誤都可以被捕捉到。
現在，所有以代碼為基礎的調試方法你都學會了，馬上把他們加入到你的工程裡去吧。最好能把它們變為你的習慣。這將對你的程序有很大幫助。
