從零開始學Python-Day49-調試

程序能一次寫完並正常運行的概率很小,基本不超過1%。總會有各種各樣的bug需要修正。有的bug很簡單,看看錯誤信息就知道,有的bug很複雜,我們需要知道出錯時,哪些變量的值是正確的,哪些變量的值是錯誤的,因此,需要一整套調試程序的手段來修復bug。

第一種方法簡單直接粗暴有效,就是用print()把可能有問題的變量打印出來看看:

從零開始學Python-Day49-調試

用print()最大的壞處是將來還得刪掉它,想想程序裡到處都是print(),運行結果也會包含很多垃圾信息。所以,我們又有第二種方法。

斷言

凡是用print()來輔助查看的地方,都可以用斷言(assert)來替代:

def foo(s):

n = int(s)

assert n != 0, 'n is zero!'

return 10 / n


def main():

foo('0')

assert的意思是,表達式n != 0應該是True,否則,根據程序運行的邏輯,後面的代碼肯定會出錯。如果斷言失敗,assert語句本身就會拋出AssertionError:

程序中如果到處充斥著assert,和print()相比也好不到哪去。不過,啟動Python解釋器時可以用-O參數來關閉assert。

注意:斷言的開關“-O”是英文大寫字母O,不是數字0

關閉後,你可以把所有的assert語句當成pass來看。

logging

把print()替換為logging是第3種方式,和assert比,logging不會拋出錯誤,而且可以輸出到文件:

從零開始學Python-Day49-調試

logging.info()就可以輸出一段文本。運行,發現除了ZeroDivisionError,沒有任何信息。在import logging之後添加一行配置再試試:

從零開始學Python-Day49-調試

這就是logging的好處,它允許你指定記錄信息的級別,有debug,info,warning,error等幾個級別,當我們指定level=INFO時,logging.debug就不起作用了。同理,指定level=WARNING後,debug和info就不起作用了。這樣一來,你可以放心地輸出不同級別的信息,也不用刪除,最後統一控制輸出哪個級別的信息。

logging的另一個好處是通過簡單的配置,一條語句可以同時輸出到不同的地方,比如console和文件。

pdb

第4種方式是啟動Python的調試器pdb,讓程序以單步方式運行,可以隨時查看運行狀態。我們先準備好程序:

s = '0'

n = int(s)

print(10 / n)

以參數-m pdb啟動,pdb定位到下一步要執行的代碼:

輸入命令n可以單步執行;p 變量名可以實時查看變量;輸入命令q結束調試,退出程序。

% python3 -m pdb new.py

> /Users/hycx-woodman/Downloads/py/new/new.py(1)()

-> s = '0'

(Pdb) n

> /Users/hycx-woodman/Downloads/py/new/new.py(2)()

-> n = int(s)

(Pdb) n

> /Users/hycx-woodman/Downloads/py/new/new.py(3)()

-> print(10 / n)

(Pdb) p s

'0'

(Pdb) p n

0

(Pdb) q

hycx-woodman@zhangjiandeMacBook-Pro new %

這種通過pdb在命令行調試的方法理論上是萬能的,但實在是太麻煩了,如果有一千行代碼,要運行到第999行得敲多少命令啊。還好,我們還有另一種調試方法。

pdb.set_trace()

這個方法也是用pdb,但是不需要單步執行,我們只需要import pdb,然後,在可能出錯的地方放一個pdb.set_trace(),就可以設置一個斷點:

從零開始學Python-Day49-調試

運行代碼,程序會自動在pdb.set_trace()暫停並進入pdb調試環境,可以用命令p查看變量,或者用命令c繼續運行。這個方式比直接啟動pdb單步調試效率要高很多。

IDE

如果要比較爽地設置斷點、單步執行,就需要一個支持調試功能的IDE。這裡推薦使用Pycharm。

小結

寫程序最痛苦的事情莫過於調試,程序往往會以你意想不到的流程來運行,你期待執行的語句其實根本沒有執行,這時候,就需要調試了。

雖然用IDE調試起來比較方便,但是最後你會發現,logging才是終極武器。


分享到:


相關文章: