以我自己的職業(yè)經(jīng)歷來說，我情愿自己去針對(duì)一項(xiàng)重現(xiàn)寫代碼，也不愿意去承接別人的代碼。我想，這是大部分碼農(nóng)的心聲吧。

[[282283]]

這其中的原因有很多種，但讓人糟心的代碼的原因排第一位的肯定是追溯其的邏輯特別的困難，那排第二絕對(duì)是出了問題定位原因特別困難。

之所以會(huì)定位問題原因難，最根本的是代碼編寫者缺少的是“異常”處理思維。

1.語法格式

我們開始從Python的異常語法格式開始吧。

從上圖可以看到以下信息：

1. 四個(gè)關(guān)鍵詞：try、except、else、finally;
2. 支撐多異常監(jiān)控。

其中，

1. try 塊包含著可能引發(fā)異常的代碼;
2. except 塊則用來捕捉和處理發(fā)生的異常;
3. 如果 try 塊中沒有拋出異常，則執(zhí)行 else 塊;
4. finally 塊無論是否發(fā)生異常都會(huì)被執(zhí)行;通常用來釋放 try 塊中申請(qǐng)的資源。

我們一直知道程序代碼中，有的關(guān)鍵詞是必須要的，有的是非必須的。根據(jù)上面語法格式，我沒可以問自己：是否可以有多重組合形式呢?

2.try... 一個(gè) except 結(jié)構(gòu)

還是以一個(gè)測(cè)試0 不能做除數(shù)的異常捕捉案例。具體代碼及執(zhí)行效果如下圖：

代碼邏輯及執(zhí)行結(jié)果：

1. 接收鍵盤輸入的數(shù)字作為除數(shù)與被除數(shù);
2. try模塊中用兩個(gè)print語句來驗(yàn)證是否執(zhí)行除法運(yùn)算;
3. 由于z = x / y引發(fā)來異常，所以其后的print語句未被執(zhí)行;
4. except模塊調(diào)用Python中的系統(tǒng)異常BaseException，打印出異常信息。

3.try... 多個(gè) except 結(jié)構(gòu)

針對(duì)上述案例，我們可以進(jìn)一步捕捉更多詳細(xì)的異常。如下圖：

4.try...except...else 結(jié)

再進(jìn)一步的話，針對(duì)try正常執(zhí)行后，通過else來控制一些語句塊的執(zhí)行。見下圖：

5.try...except...finally 結(jié)構(gòu)

最后，總是會(huì)碰到不管tyr還是Except的執(zhí)行結(jié)果如何都要執(zhí)行的語句塊，這是后finally就派上用場(chǎng)了。見下圖：

總結(jié)

• Python異常處理語法中出現(xiàn)四個(gè)關(guān)鍵詞(try、except、else、finally);
• 可以拆分出四種結(jié)構(gòu)。