錯誤分為程序的錯誤和由用戶錯誤的輸入引起的錯誤，此外還有因為各種各樣意外的情況導致的錯誤，比如在磁盤滿的時候寫入、從網絡爬取東西的時候，網絡斷了。這類錯誤稱為異常
錯誤處理
普通的錯誤處理機制就是在出錯的時候返回一個錯誤代碼，但是這樣十分不方便，一是因為錯誤碼是和正常結果一樣的方式返回的，判斷起來十分不方便，二是錯誤還需要一級一級的向上報，直到錯誤處理程序。
所以高級語言通常都內置了一套 try...except...finally... 的錯誤處理機制，Python也不例外。
try:
A#如果A中的代碼執行過程中出錯，就會執行B中的代碼
except ZeroDivisionError as e:
B
finally:
C#C中的代碼無論是否出錯都會正常執行（可以不要這個）<br>。。。
如果錯誤有不同的類型，可以說使用多個except語句，每個語句處理一個類型的錯誤
另外，可以在except后面加一個else，如果沒有出錯，會執行else
Python 的錯誤其實也是一個類，所有的異常類型都是從BaseException類派生的
except在捕獲錯誤時，不但捕獲該類型的錯誤，而且還會把子類一網打盡
try:
foo()
except ValueError as e:
print('ValueError')
except UnicodeError as e:
print('UnicodeError')
#第二個except永遠也捕獲不到UnicodeError，因為UnicodeError是ValueError的子類，如果有，也被第一個except給捕獲了。
使用try...except還有一個巨大的好處，就是可以跨越多層調用，比如函數main()調用foo()，foo()調用bar()，結果bar()出錯了，這時，只要main()捕獲到了，就可以處理。也就是說，不需要在每個可能出錯的地方去捕獲錯誤，只要在合適的層次去捕獲錯誤就可以了。這樣一來，就大大減少了寫try...except...finally的麻煩。
PS：遇到問題沒人解答？需要Python學習資料？可以加點擊下方鏈接自行獲取
note.youdao.com/noteshare?id=2dce86d0c2588ae7c0a88bee34324d76
記錄錯誤
如果不捕獲錯誤，自然可以讓Python解釋器來打印出錯誤堆棧，但程序也被結束了。既然我們能捕獲錯誤，就可以把錯誤堆棧打印出來，然后分析錯誤原因，同時，讓程序繼續執行下去。
Python內置的logging模塊可以非常容易地記錄錯誤信息
通過配置，logging還可以把錯誤記錄到日志文件里，方便事后排查。
拋出錯誤
因為錯誤是class，捕獲一個錯誤就是捕獲到該class的一個實例。因此，錯誤並不是憑空產生的，而是有意創建並拋出的。Python的內置函數會拋出很多類型的錯誤，我們自己編寫的函數也可以拋出錯誤。
如果要拋出錯誤，首先根據需要，可以定義一個錯誤的class，選擇好繼承關系，然后，用raise語句拋出一個錯誤的實例
只有在有必要的時候才定義我們自己的錯誤
另外一種錯誤處理
在try...excep捕獲到異常后，還可以在except中使用 ’raise‘把異常拋出去，以便於上級處理，如果raise語句不帶參數，就會把異常原樣拋出去，我們還可以通過raise 跟一個別的異常類型來將一種錯誤的類型轉化為另外一種類型如：
try:
10 / 0
except ZeroDivisionError:
raise ValueError('input error!')
這種類型應該是一種合理的類型，而不應該將一種類型轉化為另外一種不相干的類型
程序也可以主動拋出錯誤，讓調用者來處理相應的錯誤。但是，應該在文檔中寫清楚可能會拋出哪些錯誤，以及錯誤產生的原因。
調試
斷言
我們有事再調試的時候為了省事，就直接由print打印出變量的值，斷言的作用和上面一樣，凡是可以用print來輔助查看的地方，都可以用斷言替代
斷言可以加提示信息，
def foo(s):
n = int(s)
assert n != 0, 'n is zero!'#檢查n是否是0，返回bool
return 10 / n
def main():
foo('0')
如果斷言失敗，assert語句本身就會拋出AssertionError：提示信息
啟動Python解釋器時可以用-O參數來關閉assert：
$ python -O err.py
logging
略
使用pdb方式來調試
python -m pdb fortest.py#使用-m pdb 來啟動調試
l #使用l來查看代碼
n #使用n來執行一行代碼
p 變量名#任何時候都可以輸入p加變量名來查看變量
q#使用q退出
pdb.set_trace()
這個方法也是用pdb，但是不需要單步執行，我們只需要import pdb，然后，在可能出錯的地方放一個pdb.set_trace()，就可以設置一個斷點：
運行代碼，程序會自動在pdb.set_trace()暫停並進入pdb調試環境，可以用命令p查看變量，或者用命令c繼續運行：
IDE
雖然用IDE調試起來比較方便，但是最后你會發現，logging才是終極武器。
單元測試
為什么編寫單元測試呢，因為在寫好的程序可能在以后還需要修改，這時如果由單元測試，我們就能夠保證修改后的程序在功能上和以前的相同，這一定程度上也減少了測試的繁雜性
這種以測試為驅動的開發模式最大的好處就是確保一個程序模塊的行為符合我們設計的測試用例。在將來修改的時候，可以極大程度地保證該模塊行為仍然是正確的。
接下來，作者舉了一個例子來介紹了單元測試的編寫模式，並且介紹了一些用到的函數
我們需要引入Python自帶的測試模塊unittest模塊
import unittest
編寫單元測試的時候，需要編寫一個測試類，這個類從unittest.TestCase派生
def TestDict(unittest.TestCase):
def test_init(self):
pass
以test開頭的方法就是測試方法，不以test開頭的方法就不被認為是測試方法，運行單元測試的時候不會被執行
對每一類測試都需要編寫一個測試方法，由於unittest.TestCase內置了很多判斷，我們只需要斷言這些輸出是否是我們所需要的，最常用的斷言就是assertEqual(),
self.assertEqual(abs(-1), 1) # 斷言函數返回的結果與1相等
另一種重要的斷言就是期待拋出指定類型的Error，比如通過d['empty']訪問不存在的key時，斷言會拋出KeyError：
with self.assertRaises(KeyError):
value = d['empty']
運行單元測試
兩種方法，一種直接在模塊中加入
if __name__ == '__main__':
unittest.main()
另一種方法是在命令行通過參數-m unittest直接運行單元測試
這是推薦的做法，因為這樣可以一次批量運行很多單元測試，並且，有很多工具可以自動來運行這些單元測試。
setUp和tearDown
這兩個函數可以寫在測試類中，作用就是再每個測試方法被調用之前會執行setUp（），被調用之后會執行tearDown()，可以把一些准備工作、和善后工作放到這些函數中。
-
單元測試可以有效地測試某個程序模塊的行為，是未來重構代碼的信心保證。
-
單元測試的測試用例要覆蓋常用的輸入組合、邊界條件和異常。
-
單元測試代碼要非常簡單，如果測試代碼太復雜，那么測試代碼本身就可能有bug。
-
單元測試通過了並不意味着程序就沒有bug了，但是不通過程序肯定有bug。
文檔測試
文檔測試就是運行寫在注釋中的實例代碼
文檔測試不能再調試（Debugger）模式下運行，否則會報錯
PYDEV DEBUGGER WARNING:
sys.settrace() should not be used when the debugger is being used.
This may cause the debugger to stop working correctly.
If this is needed, please check:
http://pydev.blogspot.com/2007/06/why-cant-pydev-debugger-work-with.html
to see how to restore the debug tracing back correctly.
Call Location:
File "c:\users\administrator.sc-201605202132\appdata\local\programs\python\python36\Lib\doctest.py", line 1480, in run
sys.settrace(save_trace)
很多文檔都有示例代碼，可以把這些示例代碼在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交互式命令行的輸入和輸出來判斷測試結果是否正確。只有測試異常的時候(即真正運行的結果和實例代碼中的結果不一樣的時候，就會報錯），可以用...表示中間一大段煩人的輸出。