Finding your bug is a process of confirming the many things that you believe are true — until you find one which is not true.

—Norm Matloff

第一次接觸網頁開發是兩三年前的事，那時我曾經問過計劃帶我入門前端的前輩：入門前端的標準是什么。他當時用一種極平和的語氣和我說：學會dubug。幾年后的今天我即便也寫過一點網頁工具，但還是依然沒能入門。反思一下：一是 JavaScript 學的不好，二就是不敢說自己有多少 debug 的能力。

遂放棄。

最近因為需要又要涉及一點網頁工具開發，同時因為需求整體和 R 交互比較多于是決定用 R 的 Shiny 來搞一搞。

寫了一個多星期我感覺 Shiny 確實解決了不熟悉前后端交互的人寫網頁的大多數問題，但如何 debug 的門檻還是擺在那里。比如前幾天一個高手和我吐槽寫 Shiny 時不知道改了什么突然不能正確運行了，更糟心的是還沒有任何報錯信息。當然，后來經過討論發現其實并非沒有報錯信息，只是那時他沒有找到而已。

這篇文章就結合最近學習的一點資料，大致聊聊在 Shiny 中 debug 的一些方法。

Shiny debug 主要有三個步驟，分別是調試(Debugging)，追蹤(Tracing)和錯誤處理(Error handling)。

• Debugging: 所謂的調試就是猜，然后在你認為可能有錯誤的地方設置一個斷點，再執行接下來每個語句的時候就都可以檢查程序當時所在的狀態。
• Tracing：可以在運行程序的時候收集程序運行產生的信息而無需暫停程序，在診斷系統性問題時因為我們無法頻繁的中斷使用這一方式就比較合適。
• Error handling: 在客戶端和服務器端找到錯誤的來源并確定原因。

Debugging 調試

breakpoints 斷點

說到「斷點」，我不由的想對 bug 說一句：

靜靜地陪你走了好遠好遠，連眼睛紅了都沒有發現。

如果你知道哪一行的代碼有錯（這話本身就像bug）或者猜測很可能是哪里不對，就可以直接在所在行設置一個斷點。Rstudio 只需在行號左邊點一下鼠標就會出現紅點提示標記成功。開始運行 Shiny 程序后會在斷點處停止執行，然后就可以開始逐步執??行進行代碼調試了。

如上圖所示，我們在 40 和 41 行設置了兩個斷點，現在點擊 Run App，代碼運行會在 40 行處停下，綠色的箭頭指向 41 行，并且在 console 中會有 browse輸出，如下圖所示

這個時候我們可以方便的查看環境中已有的變量，例如這里已經運行完畢的 x 變量。如果想繼續運行，可以點擊 console 里的 continue，程序又會向下運行。

現在環境中存在 x 和 bin 兩個變量，同時在 console 的 browse[2]> 處你可以進行正常的 R 操作，例如查看變量內容或者做個加法運算，甚至你可以修改當前存在環境中的變量（當然不推薦這么操作）。

說到缺點，目前 breakpoints 只可以在 Rstudio IDE 中使用，而且只能用于ShinyServer函數中；另外如果代碼很長顯然不停的斷點也很煩，同時它只能顯示發生了什么但是無法告訴你為什么有些事情沒有發生。

小結如下：

browser() 命令

其實從上面 console 的截圖也可以看到，斷點就是執行了一次類 browser() 操作。但和斷點不同的是，browser() 本身可以被寫到任何地方。寫法如下圖所示：

說明：你現在從簡書看到的為本文的付費版本，如果需要可以付費繼續閱讀。當然，完整的文章可以在我的個人博客免費閱讀，歡迎繼續查看。