## 5.10. Recover捕獲異常 通常來説,不應該對panic異常做任何處理,但有時,也許我們可以從異常中恢複,至少我們可以在程序崩潰前,做一些操作。舉個例子,當web服務器遇到不可預料的嚴重問題時,在崩潰前應該將所有的連接關閉;如果不做任何處理,會使得客戶端一直處於等待狀態。如果web服務器還在開發階段,服務器甚至可以將異常信息反饋到客戶端,幫助調試。 如果在deferred函數中調用了內置函數recover,併且定義該defer語句的函數發生了panic異常,recover會使程序從panic中恢複,併返迴panic value。導致panic異常的函數不會繼續運行,但能正常返迴。在未發生panic時調用recover,recover會返迴nil。 讓我們以語言解析器爲例,説明recover的使用場景。考慮到語言解析器的複雜性,卽使某個語言解析器目前工作正常,也無法肯定它沒有漏洞。因此,當某個異常出現時,我們不會選擇讓解析器崩潰,而是會將panic異常當作普通的解析錯誤,併附加額外信息提醒用戶報告此錯誤。 ```Go func Parse(input string) (s *Syntax, err error) { defer func() { if p := recover(); p != nil { err = fmt.Errorf("internal error: %v", p) } }() // ...parser... } ``` deferred函數幫助Parse從panic中恢複。在deferred函數內部,panic value被附加到錯誤信息中;併用err變量接收錯誤信息,返迴給調用者。我們也可以通過調用runtime.Stack往錯誤信息中添加完整的堆棧調用信息。 不加區分的恢複所有的panic異常,不是可取的做法;因爲在panic之後,無法保證包級變量的狀態仍然和我們預期一致。比如,對數據結構的一次重要更新沒有被完整完成、文件或者網絡連接沒有被關閉、獲得的鎖沒有被釋放。此外,如果寫日誌時産生的panic被不加區分的恢複,可能會導致漏洞被忽略。 雖然把對panic的處理都集中在一個包下,有助於簡化對複雜和不可以預料問題的處理,但作爲被廣泛遵守的規范,你不應該試圖去恢複其他包引起的panic。公有的API應該將函數的運行失敗作爲error返迴,而不是panic。同樣的,你也不應該恢複一個由他人開發的函數引起的panic,比如説調用者傳入的迴調函數,因爲你無法確保這樣做是安全的。 有時我們很難完全遵循規范,舉個例子,net/http包中提供了一個web服務器,將收到的請求分發給用戶提供的處理函數。很顯然,我們不能因爲某個處理函數引發的panic異常,殺掉整個進程;web服務器遇到處理函數導致的panic時會調用recover,輸出堆棧信息,繼續運行。這樣的做法在實踐中很便捷,但也會引起資源洩漏,或是因爲recover操作,導致其他問題。 基於以上原因,安全的做法是有選擇性的recover。換句話説,隻恢複應該被恢複的panic異常,此外,這些異常所占的比例應該盡可能的低。爲了標識某個panic是否應該被恢複,我們可以將panic value設置成特殊類型。在recover時對panic value進行檢査,如果發現panic value是特殊類型,就將這個panic作爲errror處理,如果不是,則按照正常的panic進行處理(在下面的例子中,我們會看到這種方式)。 下面的例子是title函數的變形,如果HTML頁面包含多個`