idea中的debug奇淫巧技

工欲善其事，必先利其器

開發過程當中，遇到運行結果和預期的不一致的時候，最有效的方法就是debug了。固然隨着開發經驗的增長，不經過debug直接看代碼有時也能定位問題，可是十分依賴經驗和運氣，本地debug仍是最直接和完全的解決方式。開發的IDE從eclipse轉到idea也好幾年了，工做中積累了一些debug經常使用的方法，作個總結，後續有新的姿式了繼續來補充。

debug

idea中，debug很是簡單，找到你要斷點的地方，鼠標左鍵點擊就會出現一個紅色小球，這就打上斷點了，用debug方式啓動程序後，觸發你要debug的方法，就會幫你停在這一行。

debug的時候，有各類變量和表達式，有些可能在代碼裏面並不直接出現，可是對你debug挺重要，這裏能夠用這個表達式計算器來幫你驗證各類表達式的值，不須要本身人工計算。點這個計算器的小圖標，而後輸入你的表達式，idea就會幫你計算出當前表達式的值。

條件斷點

條件斷點是debug中最經常使用的一個技巧，針對像for循環、遞歸等同一行代碼在同一次觸發中會反覆進入的狀況，若是沒有條件斷點，循環多少次就要在這個地方停多少次，十分麻煩，循環次數多了幾乎在這個地方就沒法斷點。比例循環10000次，當前運行異常能夠判定在6378次出了問題，若是不改代碼，在循環中的某一行根本沒法去打斷點，打了以後就要手動放行6378次才能到，這時候只能經過修改代碼，增長第6378次的判斷，而後打再新增的代碼上才能進去debug。有了條件以後，咱們能夠在斷點上設置一個boolean表達式的條件，表達式爲true的時候，纔會在斷點處停住。例如上面圖片中的例子，i是0~4的循環，咱們能夠設置一個條件「i == 3」，這樣只有在i == 3的時候，斷點纔會停住。設置條件斷點的方法是，在斷點上右鍵，彈出設置條件的面板，而後在條件中填入你的表達式，效果以下圖

能夠注意到，設置了條件斷點後，斷點icon的右下角會有一個小問號；運行起來後，並非每次運行到這行代碼都會停住，只有在知足i==3的時候，纔會停住，這樣咱們就能夠直接運行到出問題的那個循環。

單次斷點

有些狀況下，咱們但願這個斷點只生效1次就能夠了，那咱們就能夠設置一下單次斷點。 設置的方法是先打開「Breakpoints」（左邊側欄2個紅點的圖標），找到你的斷點，而後勾選上「Remove once hit」就好。

異常斷點

這個也是開發中比較經常使用的一種斷點方式。想象是否遇到過這樣的場景：運行後報了空指針異常或者其餘什麼異常，可是當前堆棧信息不夠判斷是哪一行報的，比較傳統的作法是，在方法開始的地方打一個斷點，而後一步步跟着往下走，而後看看運行到哪一步會形成異常，若是方法比較長的話，這種方式比較費時。異常斷點的意思是，並不直接在某一行設置斷點，而是在某一種異常上設置斷點，方法運行後，idea會幫你停在形成異常的這一行，這樣的話，debug起來效率就高多了。 設置異常斷點的方法是，先打開「Breakpoints」，點擊左上角的「+」，選擇到「Java Exception Breakpoints」，而後所搜你想斷點的異常，若是是自定義異常，能夠選擇到「Project」。

設置完成後，並不會在某一行出現斷點的標誌，由於運行以前idea也不知道哪一行會拋出這個異常，咱們人造了一個空指針異常來驗證，以下圖所示

咱們用debug啓動後，idea幫咱們停在了「s.length()」這裏，這裏s是空，因此會拋出空指針異常，這樣咱們就能經過異常斷點的方式，直接讓idea幫咱們定位到了拋出異常的行。

強制返回

想象是否遇到過這樣的場景：一個方法debug到底10行，咱們已經知道問題了，這時候咱們可能不想執行後面的代碼了，由於後面的代碼可能有寫數據庫、有遠程調用、有發送消息，若是走了後面的代碼咱們後續要再恢復起來會比較麻煩，這時候咱們最多見的操做是直接stop，可是很遺憾，直接stop後，後面的代碼仍是會被執行到，以下圖所示，「這句在for循環以後執行」這句話在debug結束後仍是會被打印出來。

那有沒有辦法讓後續的代碼不被執行呢？這裏就可使用強制返回。在Debug時找到Frames模塊，裏面找到當前正在debug的方法，右鍵，選擇「Force Return」，這樣就能夠強制返回了，後面的代碼不會被執行到。

以下圖效果，就沒有打印出「這句在for循環以後執行」，證實後面的代碼缺失沒有被執行

PS：有些同窗的idea可能默認沒有打開frames模塊，能夠在右邊這個小魔方這裏選擇打開

拋出異常

有些時候，咱們在調用方法的地方加了trycatch，或者用AOP的方式增長了統一的異常捕獲，可是某一次在catch模塊中處理結果和咱們預期不一致，可是咱們本身有的測試數據都不會發生異常，那咱們就很難debug到catch模塊的代碼了。這時候咱們能夠在方法執行的過程當中強制拋出某種異常，這樣就能夠保證debug到異常捕獲的代碼。 設置的方法跟強制返回相似，選擇拋出異常而且在表達式中建立想要拋出的異常便可：

如上圖所示，在method1種強制拋出了空指針異常，咱們在main方法的catch中就捕捉到了這個異常，這樣就能夠繼續debug捕捉到異常後的處理邏輯，以下圖所示

Drop Frame

在debug過程當中，有時候在一步步往下走的時候，F8按快了多走了一步，致使關鍵的一行沒有被中止到，這時候咱們只能重來一次，若是遇到不太容易觸發的分支，重來一次的代價是比較大的，有沒有辦法回溯呢？固然並無完整的上一步的功能，可是使用drop frame，可讓某個子方法從新走一遍，必定程度上起到了上一步的做用。例如當前在method1種，走到了第2行，可是第1行是咱們的關鍵行，咱們能夠drop掉method1這個方法的frame，這樣就會回到調用method1的地方，能夠再進入一遍。

第一次，過了method1的第1行，當前在第2行，選擇method1這裏的Drop Frame

這時候回退到調用menthod1的地方

能夠按F7從新進入method1內部

執行結果後，能夠看到method1的第1行的sout確實被執行了2次

後記

好了，就先整理這些吧，下次新學了debug的姿式，再來這裏補充。