如何更好更快的debug

2019-11-17 05:51:21

字體：大中小

來源：轉載

供稿：網友

　有人說web程序員不算是真正的程序員，剛聽到這句話的時候很生氣，但仔細想想，這話還是很有道理的?？梢哉f，大部分的web程序員不能算是真正的程序員，因為他們的大部分注重力在實現功能上，而對一些程序員必須要把握的東西絲毫不在意。可以這么說，還不會爬就想跑了。
　　可能你不會同意上面的話，但問一下自己，除了改改例子實現功能以外，你對一些基本的東西有多少了解？先不說那些復雜的諸如面向對象一類的東西，我們就說說簡單的排錯、糾錯吧，你做了多少？
　　想想看，作為程序員恐怕天天大多數的時間是在debug，但究竟有多少人真正把握合理的、科學的去debug呢？以前的web編程語言象asp/php/cgi等關于debug的功能很弱，但現在的c#及java提供了豐富的debug手段，但你用了多少呢？你可能對System.Data.SqlClient的每個類、每個方法、每個屬性都了如指掌，但你對System.Diagnostics了解多少呢？
　　現代的編程語言如c++ , java , c#等都十分重視對錯誤的防止、處理，在這兒我就講一下在c#里的排錯、糾錯，希望大家能從中學到一些有用的東西，希望以后不會再聽到文章開頭那句話。
　　debug最理想的狀態是什么？這個不用我說，那就是defect free，沒有bug，呵呵。但早有人說了，沒有bug那還叫程序嗎？Win2000還60000多個bug呢。所以我們要做到的是盡量防止bug，bug出現后能迅速定位問題所在，修正這個bug。.net提供了很豐富的debug手段，除了一些debug相關的nampespace，c#語言本身也有相關的內容存在。常用的有條件編譯、try/catch、trace以及斷言(Assert)等，假如你能熟練把握這些手段，綜合運用，那么debug將不再是一場惡夢，也不會像現在這樣出現一點兒問題就滿論壇追著人問：“我這兒又出錯了，為什么呀？”。下面我將分別講一下這些手段的運用。一、捕捉異常(try / catch /finally)
　　這個我不用說，大家都清楚它的作用，就是捕捉程序中所有可能導致錯誤的異常，然后加入自己的處理措施，并且使程序繼續運行，而假如不捕捉異常的話，程序將會終止，簡單的把錯誤信息發送給客戶。
所以，在進行所有可能出現錯誤的操作時都應該捕捉異常，象下面這個例子，捕捉數據庫操作可能出現的異常。/// <summary>
/// 取得數據庫連接
/// </summary>
/// <param name="a_strDatabase">數據庫名</param>
/// <param name="oa_objConnection">輸出參數，空數據庫連接</param>
public void GetConnection(string a_strDatabase , out SqlConnection oa_objConnection)
{
oa_objConnection = null ;
string strConnStr = "";
try
{
strConnStr = "server=" + m_objIni.GetWord")
+ ";database=" + a_strDatabase ;
oa_objConnection = new SqlConnection(strConnStr) ;oa_objConnection.Open() ;//log it
m_objLog.Write("數據庫連接ok") ;
}
catch(SqlException e)
{
//log it
m_objLog.Write("數據庫連接出錯" , e) ;#if DEBUG
Console.WriteLine(e.ToString()) ;
#endif//DEBUG
throw(e) ;
}
}}//end class二、條件編譯
　　java不提供條件編譯，這是我覺得java不好的一個原因之一，所以在寫java時都是自己寫一個類來實現條件編譯。那么，什么是條件編譯呢？就是當符合某一條件時編譯，不符合時就不編譯，這就方便了debug。我們經常碰到這種情況，在某一過程或方法里我們想要知道某個變量的值，比較常用的方法是在頁面或控制臺輸出這個變量的值，已確定是否是自己希望的值，但假如沒有條件編譯的話，但當你發布發行版本時需要手工刪掉這些輸出語句，費時、費力，并且輕易出錯，而假如有條件編譯，那就方便多了?？聪旅孢@個例子：
/// <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那幾句嗎？它的作用就是當DEBUG時，在控制臺輸出異常信息，以便你馬上知道出現什么錯誤，而當不是DEBUG時，那句就不會被編譯。

三、斷言(Assert)
　　斷言真是一個值得大書特書的好東西，但可惜的是80%的程序員尤其是web程序員不用它，甚至根本就沒聽說過。很難給斷言下一個定義，假如要具體說它的好處，簡直都可以寫一本書了。簡單地說，斷言就是在應該是正確的地方加一個判定已確定它真的正確（這話有些拗口，下面我會具體解釋），它的作用就是確保你的程序按照預計的目標正常運行，并且能夠幫助你迅速定位錯誤原因。斷言的機制很簡單，就象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長度必須為偶數") ;
#endifthis.m_strID = value ;
}
}//end method　　這是個很簡單的方法，就是為了存取m_strID這個成員變量的值，這個m_strID是個利用編碼規則實現樹形結構的字符串成員變量，就像這樣：010213，兩位為一間隔，通過它的長度和編碼規則可以很輕易得到它位于第幾層，它的父節點的id等等。因為兩位數為一間隔，所以這個字符串的長度必須是個偶數。
　　看到Debug.Assert那句嗎？它的作用就是判定這個字符串的長度是不是偶數，假如不是，則談出一個對話框來顯示"分類id長度必須為偶數"?；蛟S你會說看不出它有什么作用，不就是判定一個值符不符合要求嗎。本來這個程序都是你自己寫的，所以你給這個m_strID賦值時應該知道這個長度為偶數的限制，一般情況下應該都是正確的，好，現在讓我們假設這么一種情況，由于某種原因，你忘記了這個限制，而把一個長度是奇數的字符串賦給這個變量，而這時雖然有問題但程序并不報錯，繼續運行，當過了很遠時，這個錯誤顯露出來，使整個程序崩潰或最終結果不正確，這時即使程序報錯也是在離產生這個錯誤的真正原因很遠的地方，或者干脆就不報錯，這是你要找到錯誤的原因就很困難了，可能要花費幾小時甚至幾天的時間，而假如當時你加了斷言，運行到這里的時候就會終止，告訴你錯誤的原因，也就避免了后面出現的問題以及你為糾正這個問題所付出的時間和精力。
　　怎么樣，現在是不是對斷言有了一定的了解，并且有一些愛好呢？試一下吧，慢慢的你會感受到它的威力。另外需要說的一點是斷言是為了輔助deubg的，而不是進行錯誤處理的，所以一般把它和條件編譯結合使用，只有當編程、測試時才使用斷言，而當發行正是版本時應該去掉斷言，因為究竟它是要影響效率的。四、日志(log)
　　程序記不記日志恐怕是區分傳統程序員和web程序員最好的標志了。大多數應用程序都記日志，而幾乎所有的web程序都不記日志，呵呵。其實日志也是一個非凡有用的東西，假如不記錄日志，那很可能系統發生了什么、出現什么情況你都不清楚，尤其是時間一長，更輕易出現這種情況。所以，養成良好的習慣，讓你的程序寫log吧?！　‘斎?，除了上述這些，還有很多東西，如跟蹤（trace）單步調試等等，你可以自己看一下資料。
　　方法我都講了，用不用就是你的問題了，呵呵。

上一篇：編程特例篇——LOGO語言

下一篇：ＴｕｒｂｏＣ使用釋疑兩則