細談程序調試---個人啓示錄

時間 2019-11-07

標籤細談程序調試個人啓示錄简体版

原文原文鏈接

調試是一個程序員最基本的技能，其重要性甚至超過學習一門語言。不會調試的程序員就意味着他即便會一門語言，卻不能編制出任何好的軟件。固然調試工具備不少。 java

先談VC程序如何調試圖略程序員

在選擇菜單時，經過/表示分級菜單，例如File/Open表示頂級菜單File的子菜單Open。數組

1、設置 app

爲了調試一個程序，首先必須使程序中包含調試信息。通常狀況下，一個從AppWizard建立的工程中包含的Debug Configuration自動包含調試信息，可是是否是Debug版本並非程序包含調試信息的決定因素，程序設計者能夠在任意的Configuration中增長調試信息，包括Release版本。函數

爲了增長調試信息，能夠按照下述步驟進行：工具

◆打開Project settings對話框（能夠經過快捷鍵ALT+F7打開，也能夠經過IDE菜單Project/Settings打開) 學習

◆選擇C/C++頁，Category中選擇general ，則出現一個Debug Info下拉列表框，可供選擇的調試信息方式包括：　測試

命令行 Project settings 說明優化

無 None 沒有調試信息 ui

/Zd Line Numbers Only 目標文件或者可執行文件中只包含全局和導出符號以及代碼行信息，不包含符號調試信息

/Z7 C 7.0- Compatible 目標文件或者可執行文件中包含行號和全部符號調試信息，包括變量名及類型，函數及原型等

/Zi Program Database 建立一個程序庫(PDB)，包括類型信息和符號調試信息。

/ZI Program Database for Edit and Continue 除了前面/Zi的功能外，這個選項容許對代碼進行調試過程當中的修改和繼續執行。這個選項同時使#pragma設置的優化功能無效

◆選擇Link頁，選中複選框"Generate Debug Info"，這個選項將使鏈接器把調試信息寫進可執行文件和DLL

◆若是C/C++頁中設置了Program Database以上的選項，則Link incrementally能夠選擇。選中這個選項，將使程序能夠在上一次編譯的基礎上被編譯（即增量編譯），而沒必要每次都從頭開始編譯。

2、斷點

斷點是調試器設置的一個代碼位置。當程序運行到斷點時，程序中斷執行，回到調試器。斷點是最經常使用的技巧。調試時，只有設置了斷點並使程序回到調試器，才能對程序進行在線調試。

設置斷點：能夠經過下述方法設置一個斷點。首先把光標移動到須要設置斷點的代碼行上，而後

◆按F9快捷鍵

◆彈出Breakpoints對話框，方法是按快捷鍵CTRL+B或ALT+F9，或者經過菜單Edit/Breakpoints打開。打開後點擊Break at編輯框的右側的箭頭，選擇合適的位置信息。通常狀況下，直接選擇line xxx就足夠了，若是想設置不是當前位置的斷點，能夠選擇Advanced，而後填寫函數、行號和可執行文件信息。

去掉斷點：把光標移動到給定斷點所在的行，再次按F9就能夠取消斷點。同前面所述，打開Breakpoints對話框後，也能夠按照界面提示去掉斷點。

條件斷點：能夠爲斷點設置一個條件，這樣的斷點稱爲條件斷點。對於新加的斷點，能夠單擊Conditions按鈕，爲斷點設置一個表達式。當這個表達式發生改變時，程序就被中斷。底下設置包括「觀察數組或者結構的元素個數」，彷佛能夠設置一個指針所指向的內存區的大小，可是我設置一個比較的值可是改動範圍以外的內存區彷佛也致使斷點起效。最後一個設置可讓程序先執行多少次而後纔到達斷點。

數據斷點：數據斷點只能在Breakpoints對話框中設置。選擇「Data」頁，就顯示了設置數據斷點的對話框。在編輯框中輸入一個表達式，當這個表達式的值發生變化時，數據斷點就到達。通常狀況下，這個表達式應該由運算符和全局變量構成，例如：在編輯框中輸入 g_bFlag這個全局變量的名字，那麼當程序中有g_bFlag= !g_bFlag時，程序就將停在這個語句處。

消息斷點：VC也支持對Windows消息進行截獲。他有兩種方式進行截獲：窗口消息處理函數和特定消息中斷。

在Breakpoints對話框中選擇Messages頁，就能夠設置消息斷點。若是在上面那個對話框中寫入消息處理函數的名字，那麼每次消息被這個函數處理，斷點就到達（我以爲若是採用普通斷點在這個函數中截獲，效果應該同樣）。若是在底下的下拉列表框選擇一個消息，則每次這種消息到達，程序就中斷。

3、值

Watch

VC支持查看變量、表達式和內存的值。全部這些觀察都必須是在斷點中斷的狀況下進行。

觀看變量的值最簡單，當斷點到達時，把光標移動到這個變量上，停留一會就能夠看到變量的值。

VC提供一種被成爲Watch的機制來觀看變量和表達式的值。在斷點狀態下，在變量上單擊右鍵，選擇Quick Watch，就彈出一個對話框，顯示這個變量的值。

單擊Debug工具條上的Watch按鈕，就出現一個Watch視圖（Watch1,Watch2,Watch3,Watch4），在該視圖中輸入變量或者表達式，就能夠觀察變量或者表達式的值。注意：這個表達式不能有反作用，例如++運算符絕對禁止用於這個表達式中，由於這個運算符將修改變量的值，致使軟件的邏輯被破壞。

Memory

因爲指針指向的數組，Watch只能顯示第一個元素的值。爲了顯示數組的後續內容，或者要顯示一片內存的內容，可使用memory功能。在 Debug工具條上點memory按鈕，就彈出一個對話框，在其中輸入地址，就能夠顯示該地址指向的內存的內容。

Varibles

Debug工具條上的Varibles按鈕彈出一個框，顯示全部當前執行上下文中可見的變量的值。特別是當前指令涉及的變量，以紅色顯示。

寄存器

Debug工具條上的Reigsters按鈕彈出一個框，顯示當前的全部寄存器的值。

4、進程控制

VC容許被中斷的程序繼續運行、單步運行和運行到指定光標處，分別對應快捷鍵F五、F10/F11和CTRL+F10。各個快捷鍵功能以下：

快捷鍵	說明
F5	繼續運行
F10	單步，若是涉及到子函數，不進入子函數內部
F11	單步，若是涉及到子函數，進入子函數內部
CTRL+F10	運行到當前光標處。

5、Call Stack

調用堆棧反映了當前斷點處函數是被那些函數按照什麼順序調用的。單擊Debug工具條上的Call stack就顯示Call Stack對話框。在CallStack對話框中顯示了一個調用系列，最上面的是當前函數，往下依次是調用函數的上級函數。單擊這些函數名能夠跳到對應的函數中去。

6、其餘調試手段

系統提供一系列特殊的函數或者宏來處理Debug版本相關的信息，以下：

宏名/函數名	說明
TRACE	使用方法和printf徹底一致，他在output框中輸出調試信息
ASSERT	它接收一個表達式，若是這個表達式爲TRUE，則無動做，不然中斷當前程序執行。對於系統中出現這個宏致使的中斷，應該認爲你的函數調用未能知足系統的調用此函數的前提條件。例如，對於一個尚未建立的窗口調用SetWindowText等。
VERIFY	和ASSERT功能相似，所不一樣的是，在Release版本中，ASSERT不計算輸入的表達式的值，而VERIFY計算表達式的值。

7、關注

一個好的程序員不該該把全部的判斷交給編譯器和調試器，應該在程序中本身加以程序保護和錯誤定位，具體措施包括：

◆對於全部有返回值的函數，都應該檢查返回值，除非你確信這個函數調用絕對不會出錯，或者不關心它是否出錯。

◆一些函數返回錯誤，須要用其餘函數得到錯誤的具體信息。例如accept返回INVALID_SOCKET表示accept失敗，爲了查明具體的失敗緣由，應該馬上用WSAGetLastError得到錯誤碼，並針對性的解決問題。

◆有些函數經過異常機制拋出錯誤，應該用TRY-CATCH語句來檢查錯誤

◆程序員對於能處理的錯誤，應該本身在底層處理，對於不能處理的，應該報告給用戶讓他們決定怎麼處理。若是程序出了異常，卻不對返回值和其餘機制返回的錯誤信息進行判斷，只能是加大了找錯誤的難度。

另外：VC中要編制程序不該該一開始就寫cpp/h文件，而應該首先建立一個合適的工程。由於只有這樣，VC才能選擇合適的編譯、鏈接選項。對於加入到工程中的cpp文件，應該檢查是否在第一行顯式的包含stdafx.h頭文件，這是Microsoft Visual Studio爲了加快編譯速度而設置的預編譯頭文件。在這個#include "stdafx.h"行前面的全部代碼將被忽略，因此其餘頭文件應該在這一行後面被包含。

對於.c文件，因爲不能包含stdafx.h，所以能夠經過Project settings把它的預編譯頭設置爲「不使用」，方法是：

◆彈出Project settings對話框

◆選擇C/C++

◆Category選擇Precompilation Header

◆選擇不使用預編譯頭

Java程序調試技巧

System.out.println("value:"+value)；這種形式，這兩天看了些關於Java程序調試技巧的東西，總結一下，之後要積極使用：

一：一種很簡單的方法就是使用一個boolean量如：debugMode,須要看看程序的輸出時可使用:if（debugMode）System.out.println("..");

在項目完畢後把debugMode變量設爲false;這種方法的不足是：爲了啓動或者禁止debug,必須改動代碼

二：一個比上述方法稍好的是：使用Java -D:如：Java -Ddebug=true MyClass,在使用這種方法時，必須在你全部的class中添加System.getProperty("debug")來取得調試標誌，這樣第一種方法的使用，就改成：

  
 
   public static final boolean debug;    
 
      static{    
 
         String sDebug=System.getProperty("debug");    
 
         if(sDebug!=null && sDebug.equalsIngnoreCase("true"))    
 
            debug=true;    
 
         else   
 
            debug = false;    
 
      }

這樣在不更改source code的狀況下能夠直接修改Java程序調試標誌，可是這樣不夠靈活，好比你不能指定哪一部分使用調試功能，而只是要使用調試功能就必須在代碼的所有使用，這樣就引出了第三種調試方法，能夠定義一個用於調試的類。

  
 
     public class DebugManager {    
 
      
 
    public static final String SYSTEM_DEBUG_KEY="system.Debug";    
 
    public static final boolean debug;    
 
    static {    
 
        debug = toBoolean(SYSTEM_DEBUG_KEY);    
 
    }    
 
    private static boolean toBoolean(String key){    
 
     boolean debug;    
 
     String sDebug = System.getProperty(key);    
 
     if(sDebug != null && sDebug.equalsIgnoreCase("true"))    
 
      debug = true;    
 
     else   
 
      debug =false;    
 
     return debug;    
 
    }    
 
        
 
    public static boolean getSystemDebug(){    
 
     return debug;    
 
    }    
 
    public static boolean getSystemDebug(String applicationKey) {    
 
     if(debug || toBoolean(applicationKey))    
 
      return true;    
 
     else   
 
      return false;    
 
    }    
 
   }