有人說web程序員不算是真正的程序員，剛聽到這句話的時候很氣憤，但仔細想想，這話還是很有道理的�？梢哉f，大部分的web程序員不能算是真正的程序員，因為他們的大部分注意力在實現(xiàn)功能上，而對一些程序員必須要掌握的東西絲毫不在意。可以這么說，還不會爬就想跑了。
可能你不會同意上面的話，但問一下自己，除了改改例子實現(xiàn)功能以外，你對一些基本的東西有多少了解？先不說那些復(fù)雜的諸如面向?qū)ο笠活惖臇|西，我們就說說簡單的排錯、糾錯吧，你做了多少？
想想看，作為程序員恐怕每天大多數(shù)的時間是在debug，但究竟有多少人真正掌握合理的、科學(xué)的去debug呢？以前的web編程語言象asp/php/cgi等關(guān)于debug的功能很弱，但現(xiàn)在的c#及java提供了豐富的debug手段，但你用了多少呢？你可能對System.Data.SqlClient的每個類、每個方法、每個屬性都了如指掌，但你對System.Diagnostics了解多少呢？
現(xiàn)代的編程語言如c++ , java , c#等都十分重視對錯誤的防止、處理，在這兒我就講一下在c#里的排錯、糾錯，希望大家能從中學(xué)到一些有用的東西，希望以后不會再聽到文章開頭那句話。
debug最理想的狀態(tài)是什么？這個不用我說，那就是defect free，沒有bug，呵呵。但早有人說了，沒有bug那還叫程序嗎？win2000還60000多個bug呢。所以我們要做到的是盡量防止bug，bug出現(xiàn)后能迅速定位問題所在，修正這個bug。.net提供了很豐富的debug手段，除了一些debug相關(guān)的nampespace，c#語言本身也有相關(guān)的內(nèi)容存在。常用的有條件編譯、try/catch、trace以及斷言(Assert)等，如果你能熟練掌握這些手段，綜合運用，那么debug將不再是一場惡夢，也不會像現(xiàn)在這樣出現(xiàn)一點兒問題就滿論壇追著人問：“我這兒又出錯了，為什么呀？”。下面我將分別講一下這些手段的運用。

一、捕捉異常(try / catch /finally)
這個我不用說，大家都清楚它的作用，就是捕捉程序中所有可能導(dǎo)致錯誤的異常，然后加入自己的處理措施，并且使程序繼續(xù)運行，而如果不捕捉異常的話，程序?qū)�會終止，簡單的把錯誤信息發(fā)送給客戶。
所以，在進行所有可能出現(xiàn)錯誤的操作時都應(yīng)該捕捉異常，象下面這個例子，捕捉數(shù)據(jù)庫操作可能出現(xiàn)的異常。

/// <summary>
/// 取得數(shù)據(jù)庫連接
/// </summary>
/// <param name="a_strDatabase">數(shù)據(jù)庫名</param>
/// <param name="oa_objConnection">輸出參數(shù)，空數(shù)據(jù)庫連接</param>
public void GetConnection(string a_strDatabase , out SqlConnection oa_objConnection)
{
oa_objConnection = null ;
string strConnStr = "";
try
{
strConnStr = "server=" + m_objIni.GetProperty("server") + ";uid="
+ m_objIni.GetProperty("uid") + ";pwd=" + m_objIni.GetProperty("password")
+ ";database=" + a_strDatabase ;
oa_objConnection = new SqlConnection(strConnStr) ;

oa_objConnection.Open() ;

//log it
m_objLog.Write("數(shù)據(jù)庫連接ok") ;
}
catch(SqlException e)
{
//log it
m_objLog.Write("數(shù)據(jù)庫連接出錯" , e) ;

#if DEBUG
Console.WriteLine(e.ToString()) ;
#endif//DEBUG
throw(e) ;
}
}

}//end class

二、條件編譯
java不提供條件編譯，這是我覺得java不好的一個原因之一，所以在寫java時都是自己寫一個類來實現(xiàn)條件編譯。那么，什么是條件編譯呢？就是當(dāng)符合某一條件時編譯，不符合時就不編譯，這就方便了debug。我們經(jīng)常遇到這種情況，在某一過程或方法里我們想要知道某個變量的值，比較常用的方法是在頁面或控制臺輸出這個變量的值，已確定是否是自己希望的值，但如果沒有條件編譯的話，但當(dāng)你發(fā)布發(fā)行版本時需要手工刪掉這些輸出語句，費時、費力，并且容易出錯，而如果有條件編譯，那就方便多了�？聪旅孢@個例子：
/// <summary>
/// 初始化
/// </summary>
private void Initialize()
{
try
{
m_objConnManager = new ConnManager(m_strIniFilePath , "./config/newsdata.ini") ;
log = new Log("./logs/newserver.log") ;
}
catch(Exception e)
{

#if DEBUG
Console.WriteLine("初始化" + e.Message) ;
#endif//DEBUG
throw(new Exception("初始化" + e.Message)) ;

}


}

注意到其中的#if DEBUG那幾句嗎？它的作用就是當(dāng)DEBUG時，在控制臺輸出異常信息，以便你馬上知道出現(xiàn)什么錯誤，而當(dāng)不是DEBUG時，那句就不會被編譯。

三、斷言(Assert)
斷言真是一個值得大書特書的好東西，但可惜的是80%的程序員尤其是web程序員不用它，甚至根本就沒聽說過。很難給斷言下一個定義，如果要詳細說它的好處，簡直都可以寫一本書了。簡單地說，斷言就是在應(yīng)該是正確的地方加一個判斷已確定它真的正確（這話有些拗口，下面我會詳細解釋），它的作用就是確保你的程序按照預(yù)計的目標(biāo)正常運行，并且能夠幫助你迅速定位錯誤原因。斷言的機制很簡單，就象c#里的斷言方法System.Diagnostics.Debug.Assert的定義，判斷一個條件是否成立，如果不成立的話就顯示一條信息�？雌饋砗芎唵�，真的能起那么大作用嗎？讓我們看下邊這個例子。

/// <summary>
/// 存取m_strID的屬性
/// </summary>
public string ID
{
get
{
return this.m_strID ;
}
set
{
#if DEBUG
//斷言
Debug.Assert(value.Length % 2 == 0 , "分類id長度必須為偶數(shù)") ;
#endif

this.m_strID = value ;
}
}//end method

這是個很簡單的方法，就是為了存取m_strID這個成員變量的值，這個m_strID是個利用編碼規(guī)則實現(xiàn)樹形結(jié)構(gòu)的字符串成員變量，就像這樣：010213，兩位為一間隔，通過它的長度和編碼規(guī)則可以很容易得到它位于第幾層，它的父節(jié)點的id等等。因為兩位數(shù)為一間隔，所以這個字符串的長度必須是個偶數(shù)。
看到Debug.Assert那句嗎？它的作用就是判斷這個字符串的長度是不是偶數(shù)，如果不是，則談出一個對話框來顯示"分類id長度必須為偶數(shù)"。或許你會說看不出它有什么作用，不就是判斷一個值符不符合要求嗎。本來這個程序都是你自己寫的，所以你給這個m_strID賦值時應(yīng)該知道這個長度為偶數(shù)的限制，一般情況下應(yīng)該都是正確的，好，現(xiàn)在讓我們假設(shè)這么一種情況，由于某種原因，你忘記了這個限制，而把一個長度是奇數(shù)的字符串賦給這個變量，而這時雖然有問題但程序并不報錯，繼續(xù)運行，當(dāng)過了很遠時，這個錯誤顯露出來，使整個程序崩潰或最終結(jié)果不正確，這時即使程序報錯也是在離產(chǎn)生這個錯誤的真正原因很遠的地方，或者干脆就不報錯，這是你要找到錯誤的原因就很困難了，可能要花費幾小時甚至幾天的時間，而如果當(dāng)時你加了斷言，運行到這里的時候就會終止，告訴你錯誤的原因，也就避免了后面出現(xiàn)的問題以及你為糾正這個問題所付出的時間和精力。
怎么樣，現(xiàn)在是不是對斷言有了一定的了解，并且有一些興趣呢？試一下吧，慢慢的你會感受到它的威力。另外需要說的一點是斷言是為了輔助deubg的，而不是進行錯誤處理的，所以一般把它和條件編譯結(jié)合使用，只有當(dāng)編程、測試時才使用斷言，而當(dāng)發(fā)行正是版本時應(yīng)該去掉斷言，因為畢竟它是要影響效率的。

四、日志(log)
程序記不記日志恐怕是區(qū)分傳統(tǒng)程序員和web程序員最好的標(biāo)志了。大多數(shù)應(yīng)用程序都記日志，而幾乎所有的web程序都不記日志，呵呵。其實日志也是一個特別有用的東西，如果不記錄日志，那很可能系統(tǒng)發(fā)生了什么、出現(xiàn)什么情況你都不清楚，尤其是時間一長，更容易出現(xiàn)這種情況。所以，養(yǎng)成良好的習(xí)慣，讓你的程序?qū)憀og吧。

當(dāng)然，除了上述這些，還有很多東西，如跟蹤（trace）單步調(diào)試等等，你可以自己看一下資料。
方法我都講了，用不用就是你的問題了，呵呵。