Day09勺子修羅盤記
勺子有一天發現自己的羅盤壞了。於是他就去找廠家修理。廠家熱情接待了勺子。並向他介紹說這個廠經常會有勺子帶著羅盤回來修理。有的勺子要求羅盤沒有支架懸在半空（1.ZeroDivisionError：分母為0的異常），有的勺子說羅盤材質與勺子不符(2).TypeError：類型有誤的異常)，有的勺子說羅盤上沒有刻上自己名字(3).NameError：沒有定義就使用的異常)，有的勺子說羅盤太大了超過預定尺寸(4).IndexError：下標越界的異常)，有的勺子說羅盤根本就沒有給他們(5).FileNotFoundError：文件找不到的異常)。
廠長告訴他說，我們家的羅盤出廠前，都會在車間進行調試檢查（演示異常處理的方式一：try … except …）。檢查儀器類似於地鐵入口的安檢機。不同的是，我們的安檢裝置履帶兩邊會有不同的報警裝置，按照從大到小不同功能排列（except：理解它是捕獲器，後面可以定義異常類型，並且和as關鍵字配合使用；?定義多個except是合法的，但是它的執行順序是有由上往下，一旦匹配上某個except，之後的就不執行了；匹配成功就理解將異常對象捕獲住並且kill，順便會執行except內部的代碼）。當一個羅盤通過時，如果觸發了第一個報警裝置，它會立刻被該通道從履帶上捕捉，直接落到最後的封裝箱（將一定要被執行的代碼定義在finally中，不管之前的代碼怎麼樣(異常是否被解決)，finally一定會被執行。在後期的學習和開發中，我們將關閉文件、關閉數據庫連接等操作都定義finally中）。羅盤經過報警裝置後，會有其他的儀器處理羅盤（else：位置在finally前，except後；效果/作用類似於循環沒有異常對象出現，else就會被執行，反之不會被執行），然後再落到封裝箱。當然，這些報警器是我們公司自己設置的，客戶也可以自己提要求，我們來設置將其從履帶中間挖一個洞，只要羅盤落到我們的洞裡，就和被報警器抓取是一樣的（raise：手動拋出一個異常類型的對象，定義：raise 異常類型(msg)）。
廠長還說，我們這目前一共有四種機型。有的報警器只有一種功能（except 異常類型3 as e:），有的報警器有好幾種功能（except (異常類型4,異常類型5,…,異常類型m) as e:），還有個最大的報警器擁有所有的報警功能（except Exception as e:），後來我們覺得它太大了，就把做了個小一點的簡化版（except:）。
勺子好奇的問廠長，為什麼有的機子最後有箱子，有的沒有啊？廠長回答說，有的羅盤放進機器裡是要打開箱子的，但出機的時候必須要關閉（將一定要被執行的代碼定義在finally中，不管之前的代碼怎麼樣(異常是否被解決)，finally一定會被執行 ，在後期的學習和開發中，我們將關閉文件、關閉數據庫連接等操作都定義finally中）。當然有的機器在箱子剛放入的時候向裡面加了一個裝置，當羅盤完成加工後，箱子就自動合上了（引入新的語法糖： with open…操作：不需要程序員認為的去書寫close()函數）。我們的機子靈敏度很高，即使外面套了好幾個箱子，一樣能檢測到（演示異常處理的方式二：不斷往上級傳遞異常對象，回避問題的方式 ）。
勺子聽了廠長的介紹，感到很神奇。這時，勺子看到有許多一模一樣的小黃人，站成一排。隊伍第一個小黃人收到一張紙，上面寫著讓排名向後的人站在他前面的人的肩上，最後量一下站在一起有多高。小黃人接力一樣將將紙條向後傳去。最後一個接到紙條後，站在他前面的小黃人肩上，然後再繼續疊加，最後豎直站成一條直線。有個會飛的小黃人拿了一個尺子量起高度來（遞歸調用：不斷的對於某操作重復調用執行遞歸函數：在某個函數中，調用其本身(函數自己調用自己)，這個函數整體我們稱為遞歸函數遞歸函數執行，這個過程中只有進棧(開辟空間)，沒有出棧，直到最後一次調用完畢了，才逐個出棧； 所以遞歸函數在執行的時候非常的占用內存資源； 【注意】：如果執行的次數過多了，會產生內存溢出的現象； 【總結】：遞歸在之後的學習和開發環境下要慎用！！）。廠長告訴勺子，這叫遞歸法求身高。但是也是有限度的，最多只能站998個人。
勺子聽到後，驚訝不已，決定不再找廠長麻煩。
