基礎知識
錯誤指的是可能出現問題的地方出現了問題,比如打開一個檔案時失敗,這種情況在人們的意料之中 ;而異常指的是不應該出現問題的地方出現了問題,比如引用了空指針,這種情況在人們的意料之外。可見,錯誤是業務過程的一部分,而異常不是 。
Golang中引入error接口類型作為錯誤處理的标準模式,如果函數要傳回錯誤,則傳回值類型清單中肯定包含error。error處理過程類似于C語言中的錯誤碼,可逐層傳回,直到被處理。
Golang中引入兩個内置函數panic和recover來觸發和終止異常處理流程,同時引入關鍵字defer來延遲執行defer後面的函數。
一直等到包含defer語句的函數執行完畢時,延遲函數(defer後的函數)才會被執行,而不管包含defer語句的函數是通過return的正常結束,還是由于panic導緻的異常結束。你可以在一個函數中執行多條defer語句,它們的執行順序與聲明順序相反。
當程式運作時,如果遇到引用空指針、下标越界或顯式調用panic函數等情況,則先觸發panic函數的執行,然後調用延遲函數。調用者繼續傳遞panic,是以該過程一直在調用棧中重複發生:函數停止執行,調用延遲執行函數等。如果一路在延遲函數中沒有recover函數的調用,則會到達該攜程的起點,該攜程結束,然後終止其他所有攜程,包括主攜程(類似于C語言中的主線程,該攜程ID為1)。
錯誤和異常從Golang機制上講,就是error和panic的差別。很多其他語言也一樣,比如C++/Java,沒有error但有errno,沒有panic但有throw。
Golang錯誤和異常是可以互相轉換的:
- 錯誤轉異常,比如程式邏輯上嘗試請求某個URL,最多嘗試三次,嘗試三次的過程中請求失敗是錯誤,嘗試完第三次還不成功的話,失敗就被提升為異常了。
- 異常轉錯誤,比如panic觸發的異常被recover恢複後,将傳回值中error類型的變量進行指派,以便上層函數繼續走錯誤處理流程。
一個啟示
regexp包中有兩個函數Compile和MustCompile,它們的聲明如下:
func Compile(expr string) (*Regexp, error)
func MustCompile(str string) *Regexp
同樣的功能,不同的設計:
- Compile函數基于錯誤處理設計,将正規表達式編譯成有效的可比對格式,适用于使用者輸入場景。當使用者輸入的正規表達式不合法時,該函數會傳回一個錯誤。
- MustCompile函數基于異常處理設計,适用于寫死場景。當調用者明确知道輸入不會引起函數錯誤時,要求調用者檢查這個錯誤是不必要和累贅的。我們應該假設函數的輸入一直合法,當調用者輸入了不應該出現的輸入時,就觸發panic異常。
于是我們得到一個啟示:什麼情況下用錯誤表達,什麼情況下用異常表達,就得有一套規則,否則很容易出現一切皆錯誤或一切皆異常的情況。
在這個啟示下,我們給出異常處理的作用域(場景):
- 空指針引用
- 下标越界
- 除數為0
- 不應該出現的分支,比如default
- 輸入不應該引起函數錯誤
其他場景我們使用錯誤處理,這使得我們的函數接口很精煉。對于異常,我們可以選擇在一個合适的上遊去recover,并列印堆棧資訊,使得部署後的程式不會終止。
說明: Golang錯誤處理方式一直是很多人诟病的地方,有些人吐槽說一半的代碼都是"if err != nil { / 列印 && 錯誤處理 / }",嚴重影響正常的處理邏輯。當我們區分錯誤和異常,根據規則設計函數,就會大大提高可讀性和可維護性。
錯誤處理的正确姿勢
姿勢一:失敗的原因隻有一個時,不使用error
我們看一個案例:
func (self *AgentContext) CheckHostType(host_type string) error {
switch host_type {
case "virtual_machine":
return nil
case "bare_metal":
return nil
}
return errors.New("CheckHostType ERROR:" + host_type)
}
我們可以看出,該函數失敗的原因隻有一個,是以傳回值的類型應該為bool,而不是error,重構一下代碼:
func (self *AgentContext) IsValidHostType(hostType string) bool {
return hostType == "virtual_machine" || hostType == "bare_metal"
}
說明:大多數情況,導緻失敗的原因不止一種,尤其是對I/O操作而言,使用者需要了解更多的錯誤資訊,這時的傳回值類型不再是簡單的bool,而是error。
姿勢二:沒有失敗時,不使用error
error在Golang中是如此的流行,以至于很多人設計函數時不管三七二十一都使用error,即使沒有一個失敗原因。
我們看一下示例代碼:
func (self *CniParam) setTenantId() error {
self.TenantId = self.PodNs
return nil
}
對于上面的函數設計,就會有下面的調用代碼:
err := self.setTenantId()
if err != nil {
// log
// free resource
return errors.New(...)
}
根據我們的正确姿勢,重構一下代碼:
func (self *CniParam) setTenantId() {
self.TenantId = self.PodNs
}
于是調用代碼變為:
self.setTenantId()
姿勢三:error應放在傳回值類型清單的最後
對于傳回值類型error,用來傳遞錯誤資訊,在Golang中通常放在最後一個。
resp, err := http.Get(url)
if err != nil {
return nill, err
}
bool作為傳回值類型時也一樣。
value, ok := cache.Lookup(key)
if !ok {
// ...cache[key] does not exist…
}
姿勢四:錯誤值統一定義,而不是跟着感覺走
很多人寫代碼時,到處return errors.New(value),而錯誤value在表達同一個含義時也可能形式不同,比如“記錄不存在”的錯誤value可能為:
- "record is not existed."
- "record is not exist!"
- "###record is not existed!!!"
- ...
這使得相同的錯誤value撒在一大片代碼裡,當上層函數要對特定錯誤value進行統一處理時,需要漫遊所有下層代碼,以保證錯誤value統一,不幸的是有時會有漏網之魚,而且這種方式嚴重阻礙了錯誤value的重構。
于是,我們可以參考C/C++的錯誤碼定義檔案,在Golang的每個包中增加一個錯誤對象定義檔案,如下所示:
var ERR_EOF = errors.New("EOF")
var ERR_CLOSED_PIPE = errors.New("io: read/write on closed pipe")
var ERR_NO_PROGRESS = errors.New("multiple Read calls return no data or error")
var ERR_SHORT_BUFFER = errors.New("short buffer")
var ERR_SHORT_WRITE = errors.New("short write")
var ERR_UNEXPECTED_EOF = errors.New("unexpected EOF")
說明:筆者對于常量更喜歡C/C++的“全大寫+下劃線分割”的命名方式,讀者可以根據團隊的命名規範或個人喜好定制。
姿勢五:錯誤逐層傳遞時,層層都加日志
根據筆者經驗,層層都加日志非常友善故障定位。
說明:至于通過測試來發現故障,而不是日志,目前很多團隊還很難做到。如果你或你的團隊能做到,那麼請忽略這個姿勢:)
姿勢六:錯誤處理使用defer
我們一般通過判斷error的值來處理錯誤,如果目前操作失敗,需要将本函數中已經create的資源destroy掉,示例代碼如下:
func deferDemo() error {
err := createResource1()
if err != nil {
return ERR_CREATE_RESOURCE1_FAILED
}
err = createResource2()
if err != nil {
destroyResource1()
return ERR_CREATE_RESOURCE2_FAILED
}
err = createResource3()
if err != nil {
destroyResource1()
destroyResource2()
return ERR_CREATE_RESOURCE3_FAILED
}
err = createResource4()
if err != nil {
destroyResource1()
destroyResource2()
destroyResource3()
return ERR_CREATE_RESOURCE4_FAILED
}
return nil
}
當Golang的代碼執行時,如果遇到defer的閉包調用,則壓入堆棧。當函數傳回時,會按照後進先出的順序調用閉包。
對于閉包的參數是值傳遞,而對于外部變量卻是引用傳遞,是以閉包中的外部變量err的值就變成外部函數傳回時最新的err值。
根據這個結論,我們重構上面的示例代碼:
func deferDemo() error {
err := createResource1()
if err != nil {
return ERR_CREATE_RESOURCE1_FAILED
}
defer func() {
if err != nil {
destroyResource1()
}
}()
err = createResource2()
if err != nil {
return ERR_CREATE_RESOURCE2_FAILED
}
defer func() {
if err != nil {
destroyResource2()
}
}()
err = createResource3()
if err != nil {
return ERR_CREATE_RESOURCE3_FAILED
}
defer func() {
if err != nil {
destroyResource3()
}
}()
err = createResource4()
if err != nil {
return ERR_CREATE_RESOURCE4_FAILED
}
return nil
}
姿勢七:當嘗試幾次可以避免失敗時,不要立即傳回錯誤
如果錯誤的發生是偶然性的,或由不可預知的問題導緻。一個明智的選擇是重新嘗試失敗的操作,有時第二次或第三次嘗試時會成功。在重試時,我們需要限制重試的時間間隔或重試的次數,防止無限制的重試。
兩個案例:
- 我們平時上網時,嘗試請求某個URL,有時第一次沒有響應,當我們再次重新整理時,就有了驚喜。
- 團隊的一個QA曾經建議當Neutron的attach操作失敗時,最好嘗試三次,這在當時的環境下驗證果然是有效的。
姿勢八:當上層函數不關心錯誤時,建議不傳回error
對于一些資源清理相關的函數(destroy/delete/clear),如果子函數出錯,列印日志即可,而無需将錯誤進一步回報到上層函數,因為一般情況下,上層函數是不關心執行結果的,或者即使關心也無能為力,于是我們建議将相關函數設計為不傳回error。
姿勢九:當發生錯誤時,不忽略有用的傳回值
通常,當函數傳回non-nil的error時,其他的傳回值是未定義的(undefined),這些未定義的傳回值應該被忽略。然而,有少部分函數在發生錯誤時,仍然會傳回一些有用的傳回值。比如,當讀取檔案發生錯誤時,Read函數會傳回可以讀取的位元組數以及錯誤資訊。對于這種情況,應該将讀取到的字元串和錯誤資訊一起列印出來。
說明:對函數的傳回值要有清晰的說明,以便于其他人使用。
異常處理的正确姿勢
姿勢一:在程式開發階段,堅持速錯
去年學習Erlang的時候,建立了速錯的理念,簡單來講就是“讓它挂”,隻有挂了你才會第一時間知道錯誤。在早期開發以及任何釋出階段之前,最簡單的同時也可能是最好的方法是調用panic函數來中斷程式的執行以強制發生錯誤,使得該錯誤不會被忽略,因而能夠被盡快修複。
姿勢二:在程式部署後,應恢複異常避免程式終止
在Golang中,雖然有類似Erlang程序的Goroutine,但需要強調的是Erlang的挂,隻是Erlang程序的異常退出,不會導緻整個Erlang節點退出,是以它挂的影響層面比較低,而Goroutine如果panic了,并且沒有recover,那麼整個Golang程序(類似Erlang節點)就會異常退出。是以,一旦Golang程式部署後,在任何情況下發生的異常都不應該導緻程式異常退出,我們在上層函數中加一個延遲執行的recover調用來達到這個目的,并且是否進行recover需要根據環境變量或配置檔案來定,預設需要recover。
這個姿勢類似于C語言中的斷言,但還是有差別:一般在Release版本中,斷言被定義為空而失效,但需要有if校驗存在進行異常保護,盡管契約式設計中不建議這樣做。在Golang中,recover完全可以終止異常展開過程,省時省力。
我們在調用recover的延遲函數中以最合理的方式響應該異常:
- 列印堆棧的異常調用資訊和關鍵的業務資訊,以便這些問題保留可見;
- 将異常轉換為錯誤,以便調用者讓程式恢複到健康狀态并繼續安全運作。
我們看一個簡單的例子:
func funcA() error {
defer func() {
if p := recover(); p != nil {
fmt.Printf("panic recover! p: %v", p)
debug.PrintStack()
}
}()
return funcB()
}
func funcB() error {
// simulation
panic("foo")
return errors.New("success")
}
func test() {
err := funcA()
if err == nil {
fmt.Printf("err is nil\\n")
} else {
fmt.Printf("err is %v\\n", err)
}
}
我們期望test函數的輸出是:
err is foo
實際上test函數的輸出是:
err is nil
原因是panic異常處理機制不會自動将錯誤資訊傳遞給error,是以要在funcA函數中進行顯式的傳遞,代碼如下所示:
func funcA() (err error) {
defer func() {
if p := recover(); p != nil {
fmt.Println("panic recover! p:", p)
str, ok := p.(string)
if ok {
err = errors.New(str)
} else {
err = errors.New("panic")
}
debug.PrintStack()
}
}()
return funcB()
}
姿勢三:對于不應該出現的分支,使用異常處理
switch s := suit(drawCard()); s {
case "Spades":
// ...
case "Hearts":
// ...
case "Diamonds":
// ...
case "Clubs":
// ...
default:
panic(fmt.Sprintf("invalid suit %v", s))
}
姿勢四:針對入參不應該有問題的函數,使用panic設計
func MustCompile(str string) *Regexp {
regexp, error := Compile(str)
if error != nil {
panic(`regexp: Compile(` + quote(str) + `): ` + error.Error())
}
return regexp
}