try
讓我們用一個例子來看看try的機制：
try: print('try...') r = 10 / 0 except ZeroDivisionError as e: print('except:', e) finally: print('finally...') print('END')
當我們認為某些代碼可能會出錯時，就可以用try來運行這段代碼，如果執行出錯，則后續代碼不會繼續執行，而是直接跳轉至錯誤處理代碼，即except語句塊，執行完except后，如果有finally語句塊，則執行finally語句塊，至此，執行完畢。
int()函數可能會拋出ValueError，所以我們用一個except捕獲ValueError，用另一個except捕獲ZeroDivisionError。
此外，如果沒有錯誤發生，可以在except語句塊后面加一個else，當沒有錯誤發生時，會自動執行else語句：
try: r = 10 / int('2') except ValueError as e: print('ValueError:', e) except ZeroDivisionError as e: print('ZeroDivisionError:', e) else: print('no error!') finally: print('finally...')
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
如果錯誤沒有被捕獲，它就會一直往上拋，最后被Python解釋器捕獲，打印一個錯誤信息，然后程序退出。
記錄錯誤
如果不捕獲錯誤，自然可以讓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 10 / 0 ZeroDivisionError: division by zero
通過配置，logging還可以把錯誤記錄到日志文件里，方便事后排查。
拋出錯誤
因為錯誤是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
ValueError，TypeError），盡量使用Python內置的錯誤類型。
def bar(): try: foo('0') except ValueError as e: print('ValueError!') raise
在bar()函數中，我們明明已經捕獲了錯誤，但是，打印一個ValueError!后，又把錯誤通過raise語句拋出去了
捕獲錯誤目的只是記錄一下，便於后續追蹤。但是，由於當前函數不知道應該怎么處理該錯誤，所以，最恰當的方式是繼續往上拋，讓頂層調用者去處理。好比一個員工處理不了一個問題時，就把問題拋給他的老板，如果他的老板也處理不了，就一直往上拋，最終會拋給CEO去處理。
raise語句如果不帶參數，就會把當前錯誤原樣拋出。此外，在except中raise一個Error，還可以把一種類型的錯誤轉化成另一種類型：
try: 10 / 0 except ZeroDivisionError: raise ValueError('input error!')
斷言
凡是用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：$ python3 -O err.py
assert語句當成pass來看。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和文件。
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才是終極武器。
IDE
單元測試是用來對一個模塊、一個函數或者一個類來進行正確性檢驗的測試工作。
比如對函數abs()，我們可以編寫出以下幾個測試用例：
-
輸入正數，比如
1、1.2、0.99，期待返回值與輸入相同； -
輸入負數，比如
-1、-1.2、-0.99，期待返回值與輸入相反； -
輸入
0，期待返回0； -
輸入非數值類型，比如
None、[]、{}，期待拋出TypeError。
把上面的測試用例放到一個測試模塊里，就是一個完整的單元測試。
如果單元測試通過，說明我們測試的這個函數能夠正常工作。如果單元測試不通過，要么函數有bug，要么測試條件輸入不正確，總之，需要修復使單元測試能夠通過。
單元測試通過后有什么意義呢？如果我們對abs()函數代碼做了修改，只需要再跑一遍單元測試，如果通過，說明我們的修改不會對abs()函數原有的行為造成影響，如果測試不通過，說明我們的修改與原有行為不一致，要么修改代碼，要么修改測試。
這種以測試為驅動的開發模式最大的好處就是確保一個程序模塊的行為符合我們設計的測試用例。在將來修改的時候，可以極大程度地保證該模塊行為仍然是正確的。
我們來編寫一個Dict類，這個類的行為和dict一致，但是可以通過屬性來訪問，用起來就像下面這樣：
>>> d = Dict(a=1, b=2) >>> d['a'] # 1 >>> d.a # 1
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
這是推薦的做法，因為這樣可以一次批量運行很多單元測試，並且，有很多工具可以自動來運行這些單元測試。
setUp與tearDown
可以在單元測試中編寫兩個特殊的setUp()和tearDown()方法。這兩個方法會分別在每調用一個測試方法的前后分別被執行。
setUp()和tearDown()方法有什么用呢？設想你的測試需要啟動一個數據庫，這時，就可以在setUp()方法中連接數據庫，在tearDown()方法中關閉數據庫，這樣，不必在每個測試方法中重復相同的代碼：
class TestDict(unittest.TestCase): def setUp(self): print('setUp...') def tearDown(self): print('tearDown...')
可以再次運行測試看看每個測試方法調用前后是否會打印出setUp...和tearDown...。
單元測試的測試用例要覆蓋常用的輸入組合、邊界條件和異常。
文檔測試
如果你經常閱讀Python的官方文檔，可以看到很多文檔都有示例代碼。比如re模塊就帶了很多示例代碼：
>>> 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.py class 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()
運行python3 mydict2.py：
$ python3 mydict2.py
什么輸出也沒有。這說明我們編寫的doctest運行都是正確的。如果程序有問題，比如把__getattr__()方法注釋掉，再運行就會報錯：
doctest非常有用，不但可以用來測試，還可以直接作為示例代碼。通過某些文檔生成工具，就可以自動把包含doctest的注釋提取出來。用戶看文檔的時候，同時也看到了doctest。