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

一、捕捉異常(try / catch /finally)
這個(gè)我不用說，大家都清楚它的作用，就是捕捉程序中所有可能導(dǎo)致錯(cuò)誤的異常，然后加入自己的處理措施，并且使程序繼續(xù)運(yùn)行，而如果不捕捉異常的話，程序?qū)K止，簡單的把錯(cuò)誤信息發(fā)送給客戶。
所以，在進(jìn)行所有可能出現(xiàn)錯(cuò)誤的操作時(shí)都應(yīng)該捕捉異常，象下面這個(gè)例子，捕捉數(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ù)庫連接出錯(cuò)" , e) ;

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

}//end class

二、條件編譯
java不提供條件編譯，這是我覺得java不好的一個(gè)原因之一，所以在寫java時(shí)都是自己寫一個(gè)類來實(shí)現(xiàn)條件編譯。那么，什么是條件編譯呢？就是當(dāng)符合某一條件時(shí)編譯，不符合時(shí)就不編譯，這就方便了debug。我們經(jīng)常遇到這種情況，在某一過程或方法里我們想要知道某個(gè)變量的值，比較常用的方法是在頁面或控制臺輸出這個(gè)變量的值，已確定是否是自己希望的值，但如果沒有條件編譯的話，但當(dāng)你發(fā)布發(fā)行版本時(shí)需要手工刪掉這些輸出語句，費(fèi)時(shí)、費(fèi)力，并且容易出錯(cuò)，而如果有條件編譯，那就方便多了?？聪旅孢@個(gè)例子：
/// <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時(shí)，在控制臺輸出異常信息，以便你馬上知道出現(xiàn)什么錯(cuò)誤，而當(dāng)不是DEBUG時(shí)，那句就不會被編譯。

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

/// <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

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

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

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