C++ 程式設計

除錯

程式設計是一個複雜的過程，而且是由人完成的，所以它經常會導致錯誤。這使得除錯成為任何程式設計師的一項基本技能，因為除錯是程式設計的固有部分。

出於歷史原因，程式設計錯誤被稱為 bug（在 Grace Hopper 博士記錄的一臺計算機的機械繼電器中發現了一個真正的 bug，導致它發生故障），而透過程式碼，檢查它，尋找實現中的錯誤（bug）並糾正它們的過程稱為除錯。程式設計師可用的唯一幫助是可觀察輸出生成的線索。其他方法是執行自動化工具來測試或驗證程式碼或分析程式碼執行情況，這是一個 偵錯程式 可以幫助你的任務。

除錯可能非常令人沮喪，尤其是 多執行緒 程式，這些程式極難除錯，但它也可以是一項非常有趣的智力活動，有點像邏輯謎題。除錯經驗不僅會減少未來的錯誤，還會產生更好的假設，說明可能出現的問題以及改進設計的方法。

在除錯程式碼時，已經有一些已知的程式碼部分和容易出錯的情況，例如關於指標運算的問題，這是從 C 語言繼承來的一個眾所周知的弱點。在除錯中，與任何其他方法一樣，已經有一些既定的技術、程式和實踐可以使 bug 的檢測更容易（例如：Delta Debugging）。

除錯領域還包括為程式碼（或它將在其下執行的系統）建立安全。當然，這將完全取決於特定實現的設計限制和要求。

錯誤定義

程式中的 bug 被定義為程式設計師意外的行為，並非程式設計師有意為之。它發生在該程式程式碼中預期或意圖的行為沒有發生時。bug 也可以被描述為錯誤、缺陷、失誤、故障或錯誤。

大多數 bug 都是由程式設計錯誤引起的，而少數 bug 則是由外部因素（編譯器、硬體或其他系統）引起的，這些因素不在程式設計師的直接責任範圍內。包含大量 bug 或嚴重干擾其功能的 bug 的程式被稱為 有 bug 的。

詳細說明程式中 bug 的報告通常被稱為 bug 報告、故障報告、問題報告、故障報告、變更請求等等。

程式中可能出現幾種不同的 bug，區分它們有助於更快地追蹤它們。

關於 bug 起源的分類

• 組織性
  • 概念錯誤。程式碼在語法上是正確的，但程式設計師或設計師希望它做其他事情。這些錯誤可能是由於文件和實際產品之間的差異造成的。
  • 未傳播的更新；例如，程式設計師更改了“myAdd”，但忘記更改使用相同演算法的“mySubtract”。這些錯誤可以透過 不要重複自己 的哲學來緩解。
  • 註釋過時或不正確：許多程式設計師假設註釋準確地描述了程式碼。
• 外部
  • 編譯器錯誤 或由於 C++ 語言規範缺乏預設行為而導致的意外結果。
  • 外部依賴項（庫或其他軟體）的環境錯誤或作業系統錯誤/未記錄的行為。
  • 硬體錯誤或未記錄的行為。
• 算術錯誤
  • 除以零.
  • 算術溢位 或 下溢。
  • 由於 舍入 或 數值不穩定 演算法導致的 算術精度 丟失。
• 邏輯錯誤
  • 無限迴圈 和無限 遞迴。
  • 越界錯誤，迴圈時多計或少計一個。
• 語法錯誤 (拼寫錯誤)
• 資源錯誤
  • 空指標 解引用。
  • 使用 未初始化的變數。
  • 在錯誤的 資料型別 上使用其他有效的指令（參見 壓縮十進位制/二進位制編碼的十進位制）。
  • 訪問衝突.
  • 資源洩漏，其中有限的系統資源（如 記憶體 或 檔案控制代碼）因重複分配而沒有釋放而耗盡。
  • 緩衝區溢位，其中程式試圖將資料儲存到分配儲存的末尾。這可能會或可能不會導致訪問衝突或 儲存衝突。這些 bug 可以構成 安全漏洞。
  • 過度遞迴，雖然在邏輯上有效，但會導致 堆疊溢位
• 協處理器錯誤
  • 死鎖.
  • 競爭條件.
  • 臨界區、互斥 和 併發處理 的其他功能中的併發錯誤。檢查時到使用時（TOCTOU）是一種無保護的臨界區形式。

常見錯誤

常見的程式設計錯誤，bug 大多是由於缺乏經驗、注意力不集中或程式設計師將過多的責任委派給編譯器、IDE 或其他開發工具造成的。

• 使用未初始化的變數或指標。
• 忘記編譯程式碼的除錯版本和釋出版本之間的區別。
• 在 `switch` 語句中忘記使用 `break` 語句，而本意並非要執行穿透（fall-through）。
• 忘記在訪問指標成員之前檢查空指標。

// unsafe
p->doStuff(); 

// much better!
if (p) 
{
   p->doStuff(); 
}

這會導致訪問衝突（段錯誤），並使程式意外停止。

拼寫錯誤

拼寫錯誤是指在 C++ 語言中，在一些特定的情況下（語言本身比較模糊），容易犯的語法錯誤。這個詞語源於 打字錯誤，指的是打字過程中的錯誤。

忘記在行尾加 `;` 。永遠的經典！

使用錯誤的運算子，例如進行賦值操作而不是 相等性測試。在簡單的情況下，編譯器通常會發出警告。

// Example of an assignment of a number in an if statement when a comparison was meant.
if ( x = 143 ) // should be: if ( x == 143)

忘記在多行迴圈或 if 語句中新增括號。

if (x==3)
cout << x;
flag++;

理解時間

編譯時錯誤

編譯器只能在程式語法正確的情況下才能編譯程式；否則，編譯會失敗，你將無法執行你的程式。語法指的是程式的結構以及關於該結構的規則。

例如，在英文中，一個句子必須以大寫字母開頭，以句號結尾。這個句子包含語法錯誤。這個句子也是。

對於大多數人類讀者來說，一些語法錯誤並不構成重大問題，這就是為什麼我們能夠閱讀 E. E. Cummings 的詩歌，而不會出現錯誤資訊。

編譯器並不那麼寬容。如果你的程式中存在任何一個語法錯誤，編譯器會列印錯誤資訊並退出，你將無法執行你的程式。

更糟糕的是，C++ 中的語法規則比英文中的語法規則更多，而且你從編譯器得到的錯誤資訊通常不太有用。在你程式設計生涯的前幾周，你可能會花很多時間來追蹤語法錯誤。然而，隨著你經驗的積累，你會犯更少的錯誤，並且會更快地找到錯誤。

連結錯誤

大多數連結錯誤是在使用編譯器/IDE 的不當設定時生成的。大多數最新的編譯器會報告有關錯誤的一些資訊，如果你牢記連結器的功能，你將能夠輕鬆地解決它們。大多數其他型別的錯誤都是由於對語言或專案檔案設定的使用不當造成的，這會導致由於重新定義或缺少資訊而導致的程式碼衝突。

執行時錯誤

執行時錯誤，之所以這樣稱呼是因為該錯誤只有在執行程式時才會出現。

邏輯錯誤和語義錯誤

第三種類型的錯誤是邏輯錯誤或語義錯誤。如果你的程式中存在邏輯錯誤，它會成功編譯並執行，在某種意義上，計算機不會生成任何錯誤資訊，但它不會做正確的事情。它會做別的事情。具體來說，它會按照你告訴它做的事情去做。

問題在於，你編寫的程式並不是你想要編寫的程式。程式的含義（它的語義）是錯誤的。識別邏輯錯誤可能很棘手，因為它要求你反向操作，檢視程式的輸出並試圖找出它正在做什麼。

編譯器錯誤

正如我們之前所見，錯誤是每個程式設計任務都會遇到的問題。建立編譯器也不例外，事實上，建立 C++ 編譯器是一項極其複雜的程式設計任務，尤其是在語言穩定但一直在發展的情況下，而且不僅僅是標準在發展。

C++ 允許的自由度使程式設計師能夠突破可能的界限，並且期望在抽象方面提高程式碼複雜度。這導致編譯器嘗試自動化一些底層操作，以減輕程式設計師的負擔，例如程式碼最佳化、更高級別的互動以及對編譯器元件的控制，以及包含非常底層的配置可能性。所有這些功能都增加了編譯器最終生成不正確（或者在技術上正確但意外）結果的方式數量。程式設計師應該始終牢記編譯器錯誤是可能的，但極其罕見。

最常見的歸因於編譯器的錯誤之一是由於配置錯誤的最佳化選項（或無法理解它們）造成的。如果你懷疑是編譯器錯誤，首先關閉最佳化。

實驗性除錯

從本書中學習到的最重要的技能之一就是除錯。雖然除錯可能會讓人沮喪，但它卻是程式設計中最具智力挑戰性、挑戰性和趣味性的部分之一。

從某種意義上說，除錯就像偵探工作。你面臨著線索，你必須推斷導致你所見結果的過程和事件。

除錯也像實驗科學。一旦你有了關於錯誤的猜測，你就會修改程式並再次嘗試。如果你的假設是正確的，那麼你可以預測修改的結果，並且你離編寫一個有效的程式又近了一步。如果你的假設是錯誤的，你必須提出一個新的假設。正如 夏洛克·福爾摩斯 指出的，“當你排除了所有不可能的可能性，剩下的，無論多麼不可能，都一定是真相。”（摘自 阿瑟·柯南·道爾 的《四簽名》）。

對於一些人來說，程式設計和除錯是一回事。也就是說，程式設計就是逐漸除錯程式，直到它按你的意願執行。這個想法是，你應該始終從一個有效的程式開始，這個程式可以做一些事情，然後進行小的修改，並在修改過程中進行除錯，這樣你始終擁有一個有效的程式。

例如，Linux 是一個包含數千行程式碼的作業系統，但它起源於 林納斯·託瓦茲 用於探索英特爾 80386 晶片的一個簡單程式。據拉里·格林菲爾德說，“林納斯的早期專案之一是一個在列印 AAAA 和 BBBB 之間切換的程式。它後來發展成了 Linux。”（摘自 Linux 使用者指南 Beta 版 1，第 10 頁）。

耐久性/壓力測試

這種型別的測試不僅是為了檢測錯誤，也是為了標記最佳化機會。耐久性測試是透過分析多次執行相同操作來收集統計顯著資料來進行的。請注意，這種型別的測試僅限於選定的操作集以及測試過程中輸入處理的預計變化。

在執行這種型別的測試時，可以進行一些自動化操作，甚至可以處理模擬與使用者介面互動的操作。

壓力測試是耐久性測試的一種細微變化，其目的是確定甚至建立程式在處理輸入時的極限。同樣，收集的指標僅在執行的操作方面具有意義。

因此，這些測試以及任何變化將取決於它們的設計方式，並且具有極強的目標導向性，也就是說，它們只會針對正確提出的問題提供正確的答案。對結果的依賴性必須保守，因為測試人員必須承認某些事件可能沒有受到審查。這種特性使它們更適合於最佳化，因為資源使用中的瓶頸將提供比崩潰或死鎖更好的分析起點。

跟蹤

跟蹤 技術直接從硬體領域發展到 軟體工程 領域。在硬體領域，它包括對給定電路的訊號進行取樣，以驗證硬體實現的邏輯/演算法的一致性。因此，早期的程式設計師採用了該術語和功能來跟蹤軟體的執行，但有一個明顯的區別，即跟蹤不應在公開發行的版本中執行或啟用。

執行跟蹤有幾種方法，例如，在程式碼中包含報告功能，這些功能將在執行時生成其狀態的輸出（類似於編譯器和連結器生成的錯誤和警告），甚至可以使用編譯器和連結器來報告特殊訊息。另一種方法是直接與偵錯程式進行互動，在指定除錯模式下，偵錯程式與正在執行的程式碼進行互動。還可以整合全面的 日誌記錄 系統，這些系統可以大量記錄相同的資訊，並以有組織的方式記錄資訊，這一切都取決於所需功能的複雜性和詳細程度。

事件日誌與跟蹤

日誌記錄可能是最終產品的目標，但很少涵蓋主程式的直接內部運作，提供用於診斷和審計的有用除錯資訊。除錯資訊通常只對程式設計師進行除錯感興趣，此外，根據跟蹤日誌中包含的資訊型別和詳細資訊，經驗豐富的系統管理員或技術支援人員可以診斷軟體的常見問題。跟蹤是一個橫切關注點。

偵錯程式

通常，在程式執行時無法檢視程式的原始碼。這種在程式執行時“看不到內部”的能力，在除錯程式時是一個真正的障礙。最原始的檢視內部的方法是將（取決於你的程式語言）列印或顯示或展示或回顯語句插入到你的程式碼中，以顯示正在發生的事情的資訊。但是，用這種方法找到問題的位置可能是一個緩慢而痛苦的過程。這就是偵錯程式派上用場的地方。

如果你想使用偵錯程式，並且以前從未使用過，那麼你有兩個任務要完成。你的第一個任務是學習基本的偵錯程式概念和詞彙。第二個是學習如何使用你所擁有的特定偵錯程式。你的偵錯程式文件將幫助你完成第二個任務，但它可能無法幫助你完成第一個任務。在本節中，我們將透過介紹有關手頭語言的基本偵錯程式概念和術語來幫助你完成第一個任務。一旦你熟悉了這些基礎知識，那麼你的偵錯程式文件/使用對你來說就會更有意義。大多數軟體除錯是一個緩慢的手動過程，無法很好地擴充套件。

偵錯程式是一種軟體，它使你能夠以除錯模式而不是正常模式執行你的程式。在除錯模式下執行程式允許你在程式執行時檢視內部。具體來說，偵錯程式使你能夠

1. 在每個語句執行時，檢視程式中每個語句的原始碼。
2. 在你自己選擇的地方暫停或掛起程式執行。
3. 當程式暫停時，發出各種命令以檢查和更改程式的內部狀態。
4. 恢復（或繼續）執行。

值得注意的是，有一套普遍接受的偵錯程式術語和概念。大多數偵錯程式都是 Unix 控制檯偵錯程式（針對 C 語言的 dbx）的進化後代，因此它們共享從 dbx 衍生的概念和術語。許多視覺化偵錯程式只是控制檯偵錯程式的圖形包裝器，因此視覺化偵錯程式具有相同的傳承，以及相同的概念和術語集。程式設計師不斷遇到其他人遇到的相同型別的錯誤（即使透過重用程式碼在不同的語言之間也是如此）；一個常見的例子是緩衝區溢位。

偵錯程式有兩種形式：控制檯模式（或簡稱為控制檯）偵錯程式和視覺化或圖形化偵錯程式。

控制檯偵錯程式通常是語言本身的一部分，或者包含在語言的標準庫中。控制檯偵錯程式的使用者介面是鍵盤和控制檯模式視窗（Microsoft Windows 使用者將其稱為“DOS 控制檯”）。當程式在控制檯偵錯程式下執行時，原始碼行會在執行時流過控制檯視窗。一個典型的偵錯程式有許多方法來指定程式中你希望執行暫停的精確位置。當偵錯程式暫停時，它會顯示一個特殊的偵錯程式提示，指示偵錯程式正在等待鍵盤輸入。使用者輸入命令告訴偵錯程式下一步該做什麼。典型的命令是顯示某些程式變數的值，或者繼續執行程式。

視覺化偵錯程式通常作為多功能 IDE（整合開發環境）的一個元件提供。一個強大而易於使用的視覺化偵錯程式是 IDE 的一個重要賣點。視覺化偵錯程式的人機介面通常看起來像圖形文字編輯器的介面。原始碼顯示在螢幕上，與你編輯它時顯示的方式幾乎相同。偵錯程式有自己的工具欄或選單，其中包含專門的偵錯程式功能。它可能有一個特殊的偵錯程式邊距（原始碼左側的區域），用於顯示斷點的符號、當前行指標等。當偵錯程式執行時，某種視覺化指標（可能是一個黃色箭頭）將沿著此偵錯程式邊距向下移動，指示哪個語句剛剛完成執行，或哪個語句將要執行。可以透過滑鼠單擊原始碼區域、偵錯程式邊距或偵錯程式選單來呼叫偵錯程式的功能。

如何啟動偵錯程式？

如何啟動偵錯程式（或將你的程式置於除錯模式）取決於你的程式語言和你使用的偵錯程式型別。如果你使用的是控制檯偵錯程式，那麼根據你的特定偵錯程式提供的功能，你可能可以選擇幾種不同的啟動偵錯程式的方式。一種方法可能是向啟動程式執行的命令列新增一個引數（例如 -d）。如果你這樣做，那麼程式將從它開始執行的那一刻起就處於除錯模式。第二種方法可能是啟動偵錯程式，並將程式的名稱作為引數傳遞給它。例如，如果你的偵錯程式的名稱是pdb而你的程式的名稱是myProgram，那麼你可以在命令提示符下輸入pdb myProgram來啟動執行你的程式。第三種方法可能是將語句插入到程式的原始碼中，這些語句將你的程式置於除錯模式。如果你這樣做，當你啟動你的程式執行時，它將正常執行，直到它到達除錯語句。當這些語句執行時，它們會將你的程式置於除錯模式，從那時起，你將處於除錯模式。

如果你正在使用一個提供視覺化偵錯程式的 IDE，那麼通常在你的工具欄上有一個“除錯”按鈕或選單項。單擊它將啟動你的程式在除錯模式下執行。當偵錯程式執行時，某種視覺化指標將沿著偵錯程式邊距向下移動，指示哪個語句正在執行。

跟蹤你的程式

為了探索偵錯程式提供的功能，讓我們從想象你有一個簡單的偵錯程式來使用開始。這個偵錯程式非常原始，功能集非常有限。但作為一個純粹的假設偵錯程式，它比所有真正的偵錯程式都具有一個主要優勢：只要你希望有一個新的功能，這個功能就會神奇地被新增到偵錯程式的功能集中！

一開始，你的偵錯程式只有很少的能力。一旦你啟動了偵錯程式，它會顯示你的程式中一個語句的程式碼，執行該語句，然後暫停。當偵錯程式暫停時，你只能告訴它做兩件事

1. 命令 print <aVariableName> 將列印一個變數的值，以及
2. 命令 step 將執行下一條語句，然後再次暫停。

如果偵錯程式是控制檯偵錯程式，你必須在偵錯程式提示符下鍵入這些命令。如果偵錯程式是視覺化偵錯程式，你只需單擊 Next 按鈕，或在特殊的 Show Variable 視窗中鍵入一個變數名。這就是偵錯程式所擁有的所有功能。

儘管這樣一個簡單的偵錯程式相當有用，但它也非常笨拙。使用它，你很快就會發現自己希望對偵錯程式暫停的位置有更多控制，以及在你暫停偵錯程式時可以執行的一組更大的命令。

控制偵錯程式暫停的位置

你最希望的是偵錯程式不要在每條語句之後暫停。大多數程式在進入真正存在問題的區域之前會執行很多設定工作，你已經厭倦了不得不一步一步地遍歷每個設定語句才能到達真正的麻煩區域。簡而言之，你希望能夠設定斷點。斷點是一個你可以附加到程式碼行上的物件。偵錯程式執行而不暫停，直到它遇到一條帶有斷點附加的程式碼行。斷點告訴偵錯程式暫停，因此偵錯程式會暫停。

隨著斷點功能被新增到偵錯程式（希望它出現），你現在可以在問題所在程式碼段的開頭設定一個斷點，然後啟動偵錯程式。它將執行程式，直到它到達斷點。然後它會暫停，你可以開始使用 print 命令檢查情況。

但是，當你完成使用 print 命令後，你回到了之前使用 step 命令逐個單步執行程式剩餘部分的地方。你開始希望有一個 step 命令的替代方案，用於執行到下一個斷點命令。使用這樣的命令，你可以在程式中設定多個斷點。然後，當你暫停在一個斷點處時，你可以選擇使用 step 命令逐個單步執行程式碼，或者使用 run to next breakpoint 命令執行到下一個斷點。

有了我們假設的偵錯程式，希望使它成為現實！現在，你可以即時控制程式接下來將在哪裡暫停。你開始對除錯過程有了真正的控制！

執行到下一個斷點命令的引入，讓你開始思考。你能想到 step 命令的其他哪些有用的替代方案嗎？

通常你會發現自己暫停在程式碼中的一個地方，你知道接下來的 15 個語句中沒有問題。與其一個接一個地單步執行它們，你希望能夠告訴偵錯程式類似 step 15 的東西，它會在暫停之前執行接下來的 15 個語句。

在除錯程式的過程中，你經常會遇到需要呼叫子程式的語句。在這種情況下，step 命令實際上是一個 step into 命令。也就是說，它會進入子程式，並允許你逐一跟蹤子程式內部語句的執行。

然而，在很多情況下，你知道子程式中沒有問題。在這種情況下，你希望告訴偵錯程式跳過子程式呼叫，也就是說，執行子程式而不暫停子程式內部的任何語句。step over 命令是一種 step（但不要向我展示任何雜亂的細節）命令。（在一些偵錯程式中，step over 命令被稱為 next。）

當使用 step 或 step into 進入子程式時，有時會發現你到達一個子程式中不再感興趣的點。你希望能夠告訴偵錯程式 step out 或 run until subroutine end，這將導致它在遇到 return 語句（或隱式返回到呼叫者）之前不暫停執行，然後暫停。

你還會發現，step over 和 step into 命令對於迴圈和子程式都有用。當遇到迴圈結構（例如 for 語句或 do while 語句）時，能夠選擇進入迴圈執行或跳過迴圈執行將非常方便。

幾乎總會有那麼一個時刻，透過程式碼逐行執行已經學不到更多東西了。你希望有一個命令告訴偵錯程式繼續執行，或直接執行到程式結束。

即使擁有所有這些命令，如果你使用的是控制檯偵錯程式，你仍然會發現自己經常使用 step 命令，並且你已經厭倦了輸入 step 這個詞。你希望，如果你想重複一個命令，你只需在偵錯程式提示符下按下回車鍵，偵錯程式就會重複你在偵錯程式提示符下輸入的最後一個命令。瞧，願望成真了！

這是一個如此高效的功能，以至於你開始考慮控制檯偵錯程式可以提供的其他功能，以提高其易用性。你注意到，你經常需要列印多個變數，並且你經常想一遍又一遍地列印相同的變數集。你希望有一種方法可以為一組命令建立宏或別名。例如，你可能希望定義一個別名為 foo 的宏，該宏包含一組偵錯程式列印語句。一旦定義了 foo，那麼在偵錯程式提示符下輸入 foo 就會執行宏中的語句，就像你直接在偵錯程式提示符下輸入它們一樣。

永續性

最終，工作日結束了。你的除錯工作還沒有完成。你從電腦上登出，回家享受應得的休息。第二天早上，你精神抖擻地來到辦公室，準備繼續除錯。你啟動電腦，開啟偵錯程式，發現你前一天定義的所有別名、斷點和觀察點都消失了！現在，你對偵錯程式有一個非常大的願望。你希望它具有一定的永續性。你希望它能夠記住這些東西，這樣你就不必每次啟動新的除錯會話時都重新建立它們。

你可以在偵錯程式提示符下定義別名，這對於需要為特殊場合發明的別名來說非常棒。但是，通常情況下，在每個除錯會話中都需要一組別名。也就是說，你希望能夠儲存別名定義，並在啟動任何除錯會話時自動重新建立這些別名。

大多數偵錯程式允許你建立一個包含別名定義的檔案。該檔案被賦予一個特殊名稱。當偵錯程式啟動時，它會查詢具有該特殊名稱的檔案，並自動載入這些別名定義。

檢查呼叫堆疊

當你步程序序時，你可能想知道的一個問題是“我如何到達程式碼中的這個位置？”這個問題的答案在於當前語句的呼叫堆疊（也稱為執行堆疊）。呼叫堆疊是一個列表，其中列出了進入當前語句的所有函式。例如，如果主程式模組是 MAIN，而 MAIN 呼叫函式 A，函式 A 呼叫函式 B，函式 B 呼叫函式 C，而函式 C 包含語句 S，那麼語句 S 的執行堆疊是

MAIN
    A
     B
      C
       statement S

在許多解釋性語言中，如果你的程式崩潰，直譯器會為你列印呼叫堆疊作為堆疊跟蹤。

條件斷點

一些偵錯程式允許你為斷點附加一組條件。你可能可以指定偵錯程式只在滿足某個條件時（例如VariableX > 100）或某個變數的值自上次遇到斷點以來已更改時暫停在斷點處。例如，你可以將斷點設定為在某個計數器達到某個值（例如 100）時中斷。這將允許迴圈執行 100 次然後中斷。

帶有條件附加的斷點稱為條件斷點。沒有條件附加的斷點稱為無條件或簡單斷點。在一些偵錯程式中，所有斷點都附加了條件，而“無條件”斷點只是條件為true的斷點。

觀察點

一些偵錯程式支援一種稱為觀察或觀察點的斷點。觀察點是一種條件斷點，它不與任何特定行相關聯，而是與變數相關聯。當你想在某個變數的值改變時暫停時，觀察點非常有用。在你的程式碼中搜索，查詢每個更改變數值的程式碼行，並在這些程式碼行上設定斷點，這既費力又容易出錯。觀察點允許你透過將斷點與變數而不是原始碼中的點關聯來避免所有這些操作。一旦定義了觀察點，它就會“觀察”它的變數。每當變數的值改變時，程式碼就會暫停，你可能會收到一條訊息，告訴你執行暫停的原因。然後，你可以檢視你在程式碼中的位置以及變數的值。

在視覺化偵錯程式中設定斷點

建立（或“設定”或“插入”）斷點的方式將取決於你的特定偵錯程式，尤其是它是否是一個視覺化偵錯程式或一個控制檯模式偵錯程式。在本節中，我們將討論如何在視覺化偵錯程式中設定斷點，在下一節中，我們將討論如何在控制檯模式偵錯程式中設定斷點。

視覺化偵錯程式通常允許你滾動瀏覽程式碼，直到找到要設定斷點的點。將游標放在要插入斷點的程式碼行上，然後按一個特殊的熱鍵或單擊偵錯程式工具欄上的選單項或圖示。如果有一個圖示可用，它可能暗示觀察的行為，例如它可能看起來像一副眼鏡或望遠鏡。此時，可能會彈出一個特殊的對話方塊，允許你指定斷點是有條件的還是無條件的，以及（如果是有條件的）允許你指定與斷點相關的條件。

放置斷點後，許多視覺化偵錯程式會在邊距中放置一個紅點或一個紅色八邊形（類似於美國/歐洲交通"STOP" 標誌），以指示程式碼中該位置存在斷點。