第十章 錯誤、調試和測試
Python內置了一套異常處理機制，來幫助我們進行錯誤處理。
Python的pdb可以讓我們以單步方式執行代碼。
最後，編寫測試也很重要。
10.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也不例外。
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()調用foo()，foo()調用bar()，結果bar()出錯了，這時，只要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的麻煩。
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.py
Traceback (most recent call last):
File "err.py", line 11, in <module>
main()
File "err.py", line 9, in main
bar('0')
File "err.py", line 6, in bar
return foo(s) * 2
File "err.py", line 3, in foo
return 10 / int(s)
ZeroDivisionError: division by zero
出錯並不可怕，可怕的是不知道哪裏出錯了。解讀錯誤信息是定位錯誤的關鍵。我們從上往下可以看到整個錯誤的調用函數鏈：
錯誤信息第1行：
Traceback (most recent call last):
告訴我們這是錯誤的跟蹤信息。
第2~3行：
File "err.py", line 11, in <module>
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時出錯，至此，找到錯誤源頭。
3、記錄錯誤
如果不捕獲錯誤，自然可以讓Python解釋器來打印出錯誤堆棧，但程序也被結束了。既然我們能捕獲錯誤，就可以把錯誤堆棧打印出來，然後分析錯誤原因，同時，讓程序繼續執行下去。
Python內置的logging模塊可以非常容易地記錄錯誤信息：
# err_logging.py
import 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.py
ERROR: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還可以把錯誤記錄到日誌文件裏，方便事後排查。
4、拋出錯誤
因爲錯誤是class，捕獲一個錯誤就是捕獲到該class的一個實例。因此，錯誤並不是憑空產生的，而是有意創建並拋出的。Python的內置函數會拋出很多類型的錯誤，我們自己編寫的函數也可以拋出錯誤。
如果要拋出錯誤，首先根據需要，可以定義一個錯誤的class，選擇好繼承關係，然後，用raise語句拋出一個錯誤的實例：
# err_raise.py
class 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 <module>
foo('0')
File "err_throw.py", line 8, in foo
raise FooError('invalid value: %s' % s)
__main__.FooError: invalid value: 0
只有在必要的時候才定義我們自己的錯誤類型。如果可以選擇Python已有的內置的錯誤類型（比如ValueError，TypeError），儘量使用Python內置的錯誤類型。
5、最後，我們來看另一種錯誤處理的方式：
# err_reraise.py
def 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用來處理錯誤十分方便。
出錯時，會分析錯誤信息並定位錯誤發生的代碼位置纔是最關鍵的。
程序也可以主動拋出錯誤，讓調用者來處理相應的錯誤。
但是，應該在文檔中寫清楚可能會拋出哪些錯誤，以及錯誤產生的原因。
10.2 調試
程序能一次寫完並正常運行的概率很小，基本不超過1%。總會有各種各樣的bug需要修正。有的bug很簡單，看看錯誤信息就知道，有的bug很複雜，我們需要知道出錯時，哪些變量的值是正確的，哪些變量的值是錯誤的，因此，需要一整套調試程序的手段來修復bug。
1、print（）
第一種方法簡單直接粗暴有效，就是用print()把可能有問題的變量打印出來看看：
def foo(s):
n = int(s)
print('>>> n = %d' % n)
return 10 / n
def main():
foo('0')
main()
執行後在輸出中查找打印的變量值：
$ python3 err.py
>>> n = 0
Traceback (most recent call last):
...
ZeroDivisionError: integer division or modulo by zero
用print()最大的壞處是將來還得刪掉它，想想程序裏到處都是print()，運行結果也會包含很多垃圾信息。
所以，我們又有第二種方法。
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：
$ python3 err.py
Traceback (most recent call last):
...
AssertionError: n is zero!
程序中如果到處充斥着assert，和print()相比也好不到哪去。不過，啓動Python解釋器時可以用-O參數來關閉assert：
$ python3 -O err.py
Traceback (most recent call last):
...
ZeroDivisionError: division by zero
關閉後，你可以把所有的assert語句當成pass來看。
3、logging
把print()替換爲logging是第3種方式，和assert比，logging不會拋出錯誤，而且可以輸出到文件：
import logging
s = '0'
n = int(s)
logging.info('n = %d' % n)
print(10 / n)
logging.info()就可以輸出一段文本。運行，發現除了ZeroDivisionError，沒有任何信息。怎麼回事？
別急，在import logging之後添加一行配置再試試：
import logging
logging.basicConfig(level=logging.INFO)
看到輸出了：
$ python3 err.py
INFO:root:n = 0
Traceback (most recent call last):
File "err.py", line 8, in <module>
print(10 / n)
ZeroDivisionError: division by zero
這就是logging的好處，它允許你指定記錄信息的級別，有debug，info，warning，error等幾個級別，當我們指定level=INFO時，logging.debug就不起作用了。同理，指定level=WARNING後，debug和info就不起作用了。這樣一來，你可以放心地輸出不同級別的信息，也不用刪除，最後統一控制輸出哪個級別的信息。
logging的另一個好處是通過簡單的配置，一條語句可以同時輸出到不同的地方，比如console和文件。
4、pdb
第4種方式是啓動Python的調試器pdb，讓程序以單步方式運行，可以隨時查看運行狀態。我們先準備好程序：
# err.py
s = '0'
n = int(s)
print(10 / n)
然後啓動：
$ python3 -m pdb err.py
> /Users/michael/Github/learn-python3/samples/debug/err.py(2)<module>()
-> 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)<module>()
-> n = int(s)
(Pdb) n
> /Users/michael/Github/learn-python3/samples/debug/err.py(4)<module>()
-> print(10 / n)
任何時候都可以輸入命令p 變量名來查看變量：
(Pdb) p s
'0'
(Pdb) p n
0
輸入命令q結束調試，退出程序：
(Pdb) q
這種通過pdb在命令行調試的方法理論上是萬能的，但實在是太麻煩了，如果有一千行代碼，要運行到第999行得敲多少命令啊。還好，我們還有另一種調試方法。
pdb.set_trace()
這個方法也是用pdb，但是不需要單步執行，我們只需要import pdb，然後，在可能出錯的地方放一個pdb.set_trace()，就可以設置一個斷點：
# err.py
import pdb
s = '0'
n = int(s)
pdb.set_trace() # 運行到這裏會自動暫停
print(10 / n)
運行代碼，程序會自動在pdb.set_trace()暫停並進入pdb調試環境，可以用命令p查看變量，或者用命令c繼續運行：
$ python3 err.py
> /Users/michael/Github/learn-python3/samples/debug/err.py(7)<module>()
-> print(10 / n)
(Pdb) p n
0
(Pdb) c
Traceback (most recent call last):
File "err.py", line 7, in <module>
print(10 / n)
ZeroDivisionError: division by zero
這個方式比直接啓動pdb單步調試效率要高很多，但也高不到哪去。
IDE
如果要比較爽地設置斷點、單步執行，就需要一個支持調試功能的IDE。目前比較好的Python IDE有PyCharm：
http://www.jetbrains.com/pycharm/
另外，Eclipse加上pydev插件也可以調試Python程序。
【小結】
寫程序最痛苦的事情莫過於調試，程序往往會以你意想不到的流程來運行，你期待執行的語句其實根本沒有執行，這時候，就需要調試了。
雖然用IDE調試起來比較方便，但是最後你會發現，logging纔是終極武器。
10.3 單元測試
如果單元測試通過，說明我們測試的這個函數能夠正常工作。如果單元測試不通過，要麼函數有bug，要麼測試條件輸入不正確，總之，需要修復使單元測試能夠通過。
這種以測試爲驅動的開發模式最大的好處就是確保一個程序模塊的行爲符合我們設計的測試用例。在將來修改的時候，可以極大程度地保證該模塊行爲仍然是正確的。
我們來編寫一個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 unittest
from 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
運行單元測試
一旦編寫好單元測試，我們就可以運行單元測試。最簡單的運行方式是在mydict_test.py的最後加上兩行代碼：
if __name__ == '__main__':
unittest.main()
這樣就可以把mydict_test.py當做正常的python腳本運行：
$ python3 mydict_test.py
另一種方法是在命令行通過參數-m unittest直接運行單元測試：
$ python3 -m unittest mydict_test
.....
Ran 5 tests in 0.000s
OK
這是推薦的做法，因爲這樣可以一次批量運行很多單元測試，並且，有很多工具可以自動來運行這些單元測試。
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。
10.4 文檔測試
Python內置的“文檔測試”（doctest）模塊可以直接提取註釋中的代碼並執行測試。
doctest嚴格按照Python交互式命令行的輸入和輸出來判斷測試結果是否正確。只有測試異常的時候，可以用...表示中間一大段煩人的輸出。