cfree运行程序错误的原因_Python入门教程 | 第 8 章 错误、调试和测试
第八章 錯誤、調試和測試
在程序運行過程中，總會遇到各種各樣的錯誤。
有的錯誤是程序編寫有問題造成的，比如本來應該輸出整數結果輸出了字符串，這種錯誤我們通常稱之為bug，bug是必須修復的。
有的錯誤是用戶輸入造成的，比如讓用戶輸入email地址，結果得到一個空字符串，這種錯誤可以通過檢查用戶輸入來做相應的處理。
還有一類錯誤是完全無法在程序運行過程中預測的，比如寫入文件的時候，磁盤滿了，寫不進去了，或者從網絡抓取數據，網絡突然斷掉了。這類錯誤也稱為異常，在程序中通常是必須處理的，否則，程序會因為各種問題終止并退出。
Python內置了一套異常處理機制，來幫助我們進行錯誤處理。
此外，我們也需要跟蹤程序的執行，查看變量的值是否正確，這個過程稱為調試。Python的pdb可以讓我們以單步方式執行代碼。
最后，編寫測試也很重要。有了良好的測試，就可以在程序修改后反復運行，確保程序輸出符合我們編寫的測試。
8.1 錯誤處理
在程序運行的過程中，如果發生了錯誤，可以事先約定返回一個錯誤代碼，這樣，就可以知道是否有錯，以及出錯的原因。在操作系統提供的調用中，返回錯誤碼非常常見。比如打開文件的函數open()，成功時返回文件描述符(就是一個整數)，出錯時返回-1。
用錯誤碼來表示是否出錯十分不便，因為函數本身應該返回的正常結果和錯誤碼混在一起，造成調用者必須用大量的代碼來判斷是否出錯：
def?foo():????r?=?some_function()
????if?r==(-1):
????????return?(-1)
????#?do?something
????return?r
def?bar():
????r?=?foo()
????if?r==(-1):
????????print('Error')
????else:
????????pass
一旦出錯，還要一級一級上報，直到某個函數可以處理該錯誤(比如，給用戶輸出一個錯誤信息)。
所以高級語言通常都內置了一套try...except...finally...的錯誤處理機制，Python也不例外。
8.1.1 try
讓我們用一個例子來看看try的機制：
try:????print('try...')
????r?=?10?/?0
????print('result:',?r)
except?ZeroDivisionError?as?e:
????print('except:',?e)
finally:
????print('finally...')
print('END')
當我們認為某些代碼可能會出錯時，就可以用try來運行這段代碼，如果執行出錯，則后續代碼不會繼續執行，而是直接跳轉至錯誤處理代碼，即except語句塊，執行完except后，如果有finally語句塊，則執行finally語句塊，至此，執行完畢。
上面的代碼在計算10 / 0時會產生一個除法運算錯誤：
try...except:?division?by?zero
finally...
END
從輸出可以看到，當錯誤發生時，后續語句print('result:', r)不會被執行，except由于捕獲到ZeroDivisionError，因此被執行。最后，finally語句被執行。然后，程序繼續按照流程往下走。
如果把除數0改成2，則執行結果如下：
try...result:?5
finally...
END
由于沒有錯誤發生，所以except語句塊不會被執行，但是finally如果有，則一定會被執行(可以沒有finally語句)。
你還可以猜測，錯誤應該有很多種類，如果發生了不同類型的錯誤，應該由不同的except語句塊處理。沒錯，可以有多個except來捕獲不同類型的錯誤：
try:????print('try...')
????r?=?10?/?int('a')
????print('result:',?r)
except?ValueError?as?e:
????print('ValueError:',?e)
except?ZeroDivisionError?as?e:
????print('ZeroDivisionError:',?e)
finally:
????print('finally...')
print('END')
int()函數可能會拋出ValueError，所以我們用一個except捕獲ValueError，用另一個except捕獲ZeroDivisionError。
此外，如果沒有錯誤發生，可以在except語句塊后面加一個else，當沒有錯誤發生時，會自動執行else語句：
try:????print('try...')
????r?=?10?/?int('2')
????print('result:',?r)
except?ValueError?as?e:
????print('ValueError:',?e)
except?ZeroDivisionError?as?e:
????print('ZeroDivisionError:',?e)
else:
????print('no?error!')
finally:
????print('finally...')
print('END')
Python的錯誤其實也是class，所有的錯誤類型都繼承自BaseException，所以在使用except時需要注意的是，它不但捕獲該類型的錯誤，還把其子類也“一網打盡”。比如：
try:????foo()
except?ValueError?as?e:
????print('ValueError')
except?UnicodeError?as?e:
????print('UnicodeError')
第二個except永遠也捕獲不到UnicodeError，因為UnicodeError是ValueError的子類，如果有，也被第一個except給捕獲了。
Python所有的錯誤都是從BaseException類派生的，常見的錯誤類型和繼承關系看這里：
https://docs.python.org/3/library/exceptions.html#exception-hierarchy
使用try...except捕獲錯誤還有一個巨大的好處，就是可以跨越多層調用，比如函數main()調用bar()，bar()調用foo()，結果foo()出錯了，這時，只要main()捕獲到了，就可以處理：
def?foo(s):????return?10?/?int(s)
def?bar(s):
????return?foo(s)?*?2
def?main():
????try:
????????bar('0')
????except?Exception?as?e:
????????print('Error:',?e)
????finally:
????????print('finally...')
也就是說，不需要在每個可能出錯的地方去捕獲錯誤，只要在合適的層次去捕獲錯誤就可以了。這樣一來，就大大減少了寫try...except...finally的麻煩。
8.1.2 調用棧
如果錯誤沒有被捕獲，它就會一直往上拋，最后被Python解釋器捕獲，打印一個錯誤信息，然后程序退出。來看看err.py：
#?err.py:def?foo(s):
????return?10?/?int(s)
def?bar(s):
????return?foo(s)?*?2
def?main():
????bar('0')
main()
執行，結果如下：
$?python3?err.pyTraceback?(most?recent?call?last):
??File?"err.py",?line?11,?in?
????main()
??File?"err.py",?line?9,?in?main
????bar('0')
??File?"err.py",?line?6,?in?barreturn?foo(s)?*?2
??File?"err.py",?line?3,?in?fooreturn?10?/?int(s)
ZeroDivisionError:?division?by?zero
出錯并不可怕，可怕的是不知道哪里出錯了。解讀錯誤信息是定位錯誤的關鍵。我們從上往下可以看到整個錯誤的調用函數鏈：
錯誤信息第1行：
Traceback?(most?recent?call?last):告訴我們這是錯誤的跟蹤信息。
第2~3行：
?File?"err.py",?line?11,?in?????main()
調用main()出錯了，在代碼文件err.py的第11行代碼，但原因是第9行：
?File?"err.py",?line?9,?in?main????bar('0')
調用bar('0')出錯了，在代碼文件err.py的第9行代碼，但原因是第6行：
File?"err.py",?line?6,?in?bar????return?foo(s)?*?2
原因是return foo(s) * 2這個語句出錯了，但這還不是最終原因，繼續往下看：
File?"err.py",?line?3,?in?foo????return?10?/?int(s)
原因是return 10 / int(s)這個語句出錯了，這是錯誤產生的源頭，因為下面打印了：
ZeroDivisionError:?integer?division?or?modulo?by?zero根據錯誤類型ZeroDivisionError，我們判斷，int(s)本身并沒有出錯，但是int(s)返回0，在計算10 / 0時出錯，至此，找到錯誤源頭。
!> 出錯的時候，一定要分析錯誤的調用棧信息，才能定位錯誤的位置。
異常棧8.1.3 記錄錯誤
如果不捕獲錯誤，自然可以讓Python解釋器來打印出錯誤堆棧，但程序也被結束了。既然我們能捕獲錯誤，就可以把錯誤堆棧打印出來，然后分析錯誤原因，同時，讓程序繼續執行下去。
Python內置的logging模塊可以非常容易地記錄錯誤信息：
#?err_logging.pyimport?logging
def?foo(s):
????return?10?/?int(s)
def?bar(s):
????return?foo(s)?*?2
def?main():
????try:
????????bar('0')
????except?Exception?as?e:
????????logging.exception(e)
main()
print('END')
同樣是出錯，但程序打印完錯誤信息后會繼續執行，并正常退出：
$?python3?err_logging.pyERROR:root:division?by?zero
Traceback?(most?recent?call?last):
??File?"err_logging.py",?line?13,?in?main
????bar('0')
??File?"err_logging.py",?line?9,?in?bar
????return?foo(s)?*?2
??File?"err_logging.py",?line?6,?in?foo
????return?10?/?int(s)
ZeroDivisionError:?division?by?zero
END
通過配置，logging還可以把錯誤記錄到日志文件里，方便事后排查。
8.1.4 拋出錯誤
因為錯誤是class，捕獲一個錯誤就是捕獲到該class的一個實例。因此，錯誤并不是憑空產生的，而是有意創建并拋出的。Python的內置函數會拋出很多類型的錯誤，我們自己編寫的函數也可以拋出錯誤。
如果要拋出錯誤，首先根據需要，可以定義一個錯誤的class，選擇好繼承關系，然后，用raise語句拋出一個錯誤的實例：
#?err_raise.pyclass?FooError(ValueError):
????pass
def?foo(s):
????n?=?int(s)
????if?n==0:
????????raise?FooError('invalid?value:?%s'?%?s)
????return?10?/?n
foo('0')
執行，可以最后跟蹤到我們自己定義的錯誤：
$?python3?err_raise.py?Traceback?(most?recent?call?last):
??File?"err_throw.py",?line?11,?in?
????foo('0')
??File?"err_throw.py",?line?8,?in?fooraise?FooError('invalid?value:?%s'?%?s)
__main__.FooError:?invalid?value:?0
只有在必要的時候才定義我們自己的錯誤類型。如果可以選擇Python已有的內置的錯誤類型(比如ValueError，TypeError)，盡量使用Python內置的錯誤類型。
最后，我們來看另一種錯誤處理的方式：
#?err_reraise.pydef?foo(s):
????n?=?int(s)
????if?n==0:
????????raise?ValueError('invalid?value:?%s'?%?s)
????return?10?/?n
def?bar():
????try:
????????foo('0')
????except?ValueError?as?e:
????????print('ValueError!')
????????raise
bar()
在bar()函數中，我們明明已經捕獲了錯誤，但是，打印一個ValueError!后，又把錯誤通過raise語句拋出去了，這不有病么？
其實這種錯誤處理方式不但沒病，而且相當常見。捕獲錯誤目的只是記錄一下，便于后續追蹤。但是，由于當前函數不知道應該怎么處理該錯誤，所以，最恰當的方式是繼續往上拋，讓頂層調用者去處理。好比一個員工處理不了一個問題時，就把問題拋給他的老板，如果他的老板也處理不了，就一直往上拋，最終會拋給CEO去處理。
raise語句如果不帶參數，就會把當前錯誤原樣拋出。此外，在except中raise一個Error，還可以把一種類型的錯誤轉化成另一種類型：
try:????10?/?0
except?ZeroDivisionError:
????raise?ValueError('input?error!')
只要是合理的轉換邏輯就可以，但是，決不應該把一個IOError轉換成毫不相干的ValueError。
?小結：
?Python內置的try...except...finally用來處理錯誤十分方便。出錯時，會分析錯誤信息并定位錯誤發生的代碼位置才是最關鍵的。
程序也可以主動拋出錯誤，讓調用者來處理相應的錯誤。但是，應該在文檔中寫清楚可能會拋出哪些錯誤，以及錯誤產生的原因。
8.2 調試
程序能一次寫完并正常運行的概率很小，基本不超過1%。總會有各種各樣的bug需要修正。有的bug很簡單，看看錯誤信息就知道，有的bug很復雜，我們需要知道出錯時，哪些變量的值是正確的，哪些變量的值是錯誤的，因此，需要一整套調試程序的手段來修復bug。
8.2.1 print()
第一種方法簡單直接粗暴有效，就是用print()把可能有問題的變量打印出來看看：
def?foo(s):????n?=?int(s)
????print('>>>?n?=?%d'?%?n)
????return?10?/?n
def?main():
????foo('0')
main()
執行后在輸出中查找打印的變量值：
$?python?err.py>>>?n?=?0
Traceback?(most?recent?call?last):
??...
ZeroDivisionError:?integer?division?or?modulo?by?zero
用print()最大的壞處是將來還得刪掉它，想想程序里到處都是print()，運行結果也會包含很多垃圾信息。所以，我們又有第二種方法。
8.2.2 斷言
凡是用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：
$?python?err.pyTraceback?(most?recent?call?last):
??...
AssertionError:?n?is?zero!
程序中如果到處充斥著assert，和print()相比也好不到哪去。不過，啟動Python解釋器時可以用-O參數來關閉assert：
$?python?-O?err.pyTraceback?(most?recent?call?last):
??...
ZeroDivisionError:?division?by?zero
!> 注意：斷言的開關“-O”是英文大寫字母O，不是數字0。
關閉后，你可以把所有的assert語句當成pass來看。
8.2.3 logging
把print()替換為logging是第3種方式，和assert比，logging不會拋出錯誤，而且可以輸出到文件：
import?loggings?=?'0'
n?=?int(s)
logging.info('n?=?%d'?%?n)
print(10?/?n)
logging.info()就可以輸出一段文本。運行，發現除了ZeroDivisionError，沒有任何信息。怎么回事？
別急，在import logging之后添加一行配置再試試：
import?logginglogging.basicConfig(level=logging.INFO)
看到輸出了：
$?python?err.pyINFO:root:n?=?0
Traceback?(most?recent?call?last):
??File?"err.py",?line?8,?in?
????print(10?/?n)
ZeroDivisionError:?division?by?zero
這就是logging的好處，它允許你指定記錄信息的級別，有debug，info，warning，error等幾個級別，當我們指定level=INFO時，logging.debug就不起作用了。同理，指定level=WARNING后，debug和info就不起作用了。這樣一來，你可以放心地輸出不同級別的信息，也不用刪除，最后統一控制輸出哪個級別的信息。
logging的另一個好處是通過簡單的配置，一條語句可以同時輸出到不同的地方，比如console和文件。
8.2.4 pdb
第4種方式是啟動Python的調試器pdb，讓程序以單步方式運行，可以隨時查看運行狀態。我們先準備好程序：
#?err.pys?=?'0'
n?=?int(s)
print(10?/?n)
然后啟動：
$?python?-m?pdb?err.py>?/Users/michael/Github/learn-python3/samples/debug/err.py(2)()
->?s?=?'0'
以參數-m pdb啟動后，pdb定位到下一步要執行的代碼-> s = '0'。輸入命令l來查看代碼：
(Pdb)?l??1?????#?err.py
??2??->?s?=?'0'
??3?????n?=?int(s)
??4?????print(10?/?n)
輸入命令n可以單步執行代碼：
(Pdb)?n>?/Users/michael/Github/learn-python3/samples/debug/err.py(3)()
->?n?=?int(s)
(Pdb)?n
>?/Users/michael/Github/learn-python3/samples/debug/err.py(4)()
->?print(10?/?n)
任何時候都可以輸入命令p 變量名來查看變量：
(Pdb)?p?s'0'
(Pdb)?p?n
0
輸入命令q結束調試，退出程序：
(Pdb)?q這種通過pdb在命令行調試的方法理論上是萬能的，但實在是太麻煩了，如果有一千行代碼，要運行到第999行得敲多少命令啊。還好，我們還有另一種調試方法。
8.2.5 pdb.set_trace()
這個方法也是用pdb，但是不需要單步執行，我們只需要import pdb，然后，在可能出錯的地方放一個pdb.set_trace()，就可以設置一個斷點：
#?err.pyimport?pdb
s?=?'0'
n?=?int(s)
pdb.set_trace()?#?運行到這里會自動暫停
print(10?/?n)
運行代碼，程序會自動在pdb.set_trace()暫停并進入pdb調試環境，可以用命令p查看變量，或者用命令c繼續運行：
$?python?err.py?>?/Users/michael/Github/learn-python3/samples/debug/err.py(7)()
->?print(10?/?n)
(Pdb)?p?n0
(Pdb)?c
Traceback?(most?recent?call?last):
??File?"err.py",?line?7,?in?
????print(10?/?n)
ZeroDivisionError:?division?by?zero
這個方式比直接啟動pdb單步調試效率要高很多，但也高不到哪去。
8.2.6 IDE
如果要比較爽地設置斷點、單步執行，就需要一個支持調試功能的IDE。目前比較好的Python IDE有：
- Visual Studio Code：https://code.visualstudio.com/，需要安裝Python插件。
- PyCharm：http://www.jetbrains.com/pycharm/
- 另外，Eclipse[1]加上pydev[2]插件也可以調試Python程序。
小結：
?寫程序最痛苦的事情莫過于調試，程序往往會以你意想不到的流程來運行，你期待執行的語句其實根本沒有執行，這時候，就需要調試了。
雖然用IDE調試起來比較方便，但是最后你會發現，logging才是終極武器。
8.3 單元測試
如果你聽說過“測試驅動開發”(TDD：Test-Driven Development)，單元測試就不陌生。
單元測試是用來對一個模塊、一個函數或者一個類來進行正確性檢驗的測試工作。
比如對函數abs()，我們可以編寫出以下幾個測試用例：
把上面的測試用例放到一個測試模塊里，就是一個完整的單元測試。
如果單元測試通過，說明我們測試的這個函數能夠正常工作。如果單元測試不通過，要么函數有bug，要么測試條件輸入不正確，總之，需要修復使單元測試能夠通過。
單元測試通過后有什么意義呢？如果我們對abs()函數代碼做了修改，只需要再跑一遍單元測試，如果通過，說明我們的修改不會對abs()函數原有的行為造成影響，如果測試不通過，說明我們的修改與原有行為不一致，要么修改代碼，要么修改測試。
這種以測試為驅動的開發模式最大的好處就是確保一個程序模塊的行為符合我們設計的測試用例。在將來修改的時候，可以極大程度地保證該模塊行為仍然是正確的。
我們來編寫一個Dict類，這個類的行為和dict一致，但是可以通過屬性來訪問，用起來就像下面這樣：
>>>?d?=?Dict(a=1,?b=2)>>>?d['a']
1
>>>?d.a
1
mydict.py代碼如下：
class?Dict(dict):????def?__init__(self,?**kw):
????????super().__init__(**kw)
????def?__getattr__(self,?key):
????????try:
????????????return?self[key]
????????except?KeyError:
????????????raise?AttributeError(r"'Dict'?object?has?no?attribute?'%s'"?%?key)
????def?__setattr__(self,?key,?value):
????????self[key]?=?value
為了編寫單元測試，我們需要引入Python自帶的unittest模塊，編寫mydict_test.py如下：
import?unittestfrom?mydict?import?Dict
class?TestDict(unittest.TestCase):
????def?test_init(self):
????????d?=?Dict(a=1,?b='test')
????????self.assertEqual(d.a,?1)
????????self.assertEqual(d.b,?'test')
????????self.assertTrue(isinstance(d,?dict))
????def?test_key(self):
????????d?=?Dict()
????????d['key']?=?'value'
????????self.assertEqual(d.key,?'value')
????def?test_attr(self):
????????d?=?Dict()
????????d.key?=?'value'
????????self.assertTrue('key'?in?d)
????????self.assertEqual(d['key'],?'value')
????def?test_keyerror(self):
????????d?=?Dict()
????????with?self.assertRaises(KeyError):
????????????value?=?d['empty']
????def?test_attrerror(self):
????????d?=?Dict()
????????with?self.assertRaises(AttributeError):
????????????value?=?d.empty
編寫單元測試時，我們需要編寫一個測試類，從unittest.TestCase繼承。
以test開頭的方法就是測試方法，不以test開頭的方法不被認為是測試方法，測試的時候不會被執行。
對每一類測試都需要編寫一個test_xxx()方法。由于unittest.TestCase提供了很多內置的條件判斷，我們只需要調用這些方法就可以斷言輸出是否是我們所期望的。最常用的斷言就是assertEqual()：
self.assertEqual(abs(-1),?1)?#?斷言函數返回的結果與1相等另一種重要的斷言就是期待拋出指定類型的Error，比如通過d['empty']訪問不存在的key時，斷言會拋出KeyError：
with?self.assertRaises(KeyError):????value?=?d['empty']
而通過d.empty訪問不存在的key時，我們期待拋出AttributeError：
with?self.assertRaises(AttributeError):????value?=?d.empty
8.3.1 運行單元測試
一旦編寫好單元測試，我們就可以運行單元測試。最簡單的運行方式是在mydict_test.py的最后加上兩行代碼：
if?__name__?==?'__main__':????unittest.main()
這樣就可以把mydict_test.py當做正常的python腳本運行：
$?python?mydict_test.py另一種方法是在命令行通過參數-m unittest直接運行單元測試：
$?python?-m?unittest?mydict_test.....
----------------------------------------------------------------------
Ran?5?tests?in?0.000s
OK
這是推薦的做法，因為這樣可以一次批量運行很多單元測試，并且，有很多工具可以自動來運行這些單元測試。
8.3.2 setUp 與 tearDown
可以在單元測試中編寫兩個特殊的setUp()和tearDown()方法。這兩個方法會分別在每調用一個測試方法的前后分別被執行。
setUp()和tearDown()方法有什么用呢？設想你的測試需要啟動一個數據庫，這時，就可以在setUp()方法中連接數據庫，在tearDown()方法中關閉數據庫，這樣，不必在每個測試方法中重復相同的代碼：
class?TestDict(unittest.TestCase):????def?setUp(self):
????????print('setUp...')
????def?tearDown(self):
????????print('tearDown...')
可以再次運行測試看看每個測試方法調用前后是否會打印出setUp...和tearDown...。
?小結：
?- 單元測試可以有效地測試某個程序模塊的行為，是未來重構代碼的信心保證。
- 單元測試的測試用例要覆蓋常用的輸入組合、邊界條件和異常。
- 單元測試代碼要非常簡單，如果測試代碼太復雜，那么測試代碼本身就可能有bug。
- 單元測試通過了并不意味著程序就沒有bug了，但是不通過程序肯定有bug。
8.4 文檔測試
如果你經常閱讀Python的官方文檔，可以看到很多文檔都有示例代碼。比如re模塊[3]就帶了很多示例代碼：
>>>?import?re>>>?m?=?re.search('(?<=abc)def',?'abcdef')
>>>?m.group(0)
'def'
可以把這些示例代碼在Python的交互式環境下輸入并執行，結果與文檔中的示例代碼顯示的一致。
這些代碼與其他說明可以寫在注釋中，然后，由一些工具來自動生成文檔。既然這些代碼本身就可以粘貼出來直接運行，那么，可不可以自動執行寫在注釋中的這些代碼呢？
答案是肯定的。
當我們編寫注釋時，如果寫上這樣的注釋：
def?abs(n):????'''
????Function?to?get?absolute?value?of?number.
????Example:
????>>>?abs(1)
????1
????>>>?abs(-1)
????1
????>>>?abs(0)
????0
????'''
????return?n?if?n?>=?0?else?(-n)
無疑更明確地告訴函數的調用者該函數的期望輸入和輸出。
并且，Python內置的“文檔測試”(doctest)模塊可以直接提取注釋中的代碼并執行測試。
doctest嚴格按照Python交互式命令行的輸入和輸出來判斷測試結果是否正確。只有測試異常的時候，可以用...表示中間一大段煩人的輸出。
讓我們用doctest來測試上次編寫的Dict類：
#?mydict2.pyclass?Dict(dict):
????'''
????Simple?dict?but?also?support?access?as?x.y?style.
????>>>?d1?=?Dict()
????>>>?d1['x']?=?100
????>>>?d1.x
????100
????>>>?d1.y?=?200
????>>>?d1['y']
????200
????>>>?d2?=?Dict(a=1,?b=2,?c='3')
????>>>?d2.c
????'3'
????>>>?d2['empty']
????Traceback?(most?recent?call?last):
????????...
????KeyError:?'empty'
????>>>?d2.empty
????Traceback?(most?recent?call?last):
????????...
????AttributeError:?'Dict'?object?has?no?attribute?'empty'
????'''
????def?__init__(self,?**kw):
????????super(Dict,?self).__init__(**kw)
????def?__getattr__(self,?key):
????????try:
????????????return?self[key]
????????except?KeyError:
????????????raise?AttributeError(r"'Dict'?object?has?no?attribute?'%s'"?%?key)
????def?__setattr__(self,?key,?value):
????????self[key]?=?value
if?__name__=='__main__':
????import?doctest
????doctest.testmod()
運行python mydict2.py：
$?python?mydict2.py什么輸出也沒有。這說明我們編寫的doctest運行都是正確的。如果程序有問題，比如把__getattr__()方法注釋掉，再運行就會報錯：
$?python?mydict2.py**********************************************************************
File?"/Users/michael/Github/learn-python3/samples/debug/mydict2.py",?line?10,?in?__main__.Dict
Failed?example:
????d1.x
Exception?raised:
????Traceback?(most?recent?call?last):
??????...
????AttributeError:?'Dict'?object?has?no?attribute?'x'
**********************************************************************
File?"/Users/michael/Github/learn-python3/samples/debug/mydict2.py",?line?16,?in?__main__.Dict
Failed?example:
????d2.c
Exception?raised:
????Traceback?(most?recent?call?last):
??????...
????AttributeError:?'Dict'?object?has?no?attribute?'c'
**********************************************************************
1?items?had?failures:
???2?of???9?in?__main__.Dict
***Test?Failed***?2?failures.
注意到最后3行代碼。當模塊正常導入時，doctest不會被執行。只有在命令行直接運行時，才執行doctest。所以，不必擔心doctest會在非測試環境下執行。
?小結：
?doctest非常有用，不但可以用來測試，還可以直接作為示例代碼。通過某些文檔生成工具，就可以自動把包含doctest的注釋提取出來。用戶看文檔的時候，同時也看到了doctest。
8.5 參考資料
- 廖雪峰 - Python 3.x - 錯誤、調試和測試[4]
Reference
[1]Eclipse: http://www.eclipse.org/
[2]pydev: http://pydev.org/
[3]re模塊: https://docs.python.org/3/library/re.html
[4]廖雪峰 - Python 3.x - 錯誤、調試和測試: https://www.liaoxuefeng.com/wiki/1016959663602400/1017598814713792
總結
以上是生活随笔為你收集整理的cfree运行程序错误的原因_Python入门教程 | 第 8 章 错误、调试和测试的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 英语计算机房和操场怎么读,计算机房对我们
- 下一篇： ip打包后如何加入 xilinx_科普！