前言

Golang中當(dāng)程序發(fā)生致命異常時(shí)（比如數(shù)組下標(biāo)越界，注意這里的異常并不是error），Golang程序會(huì)panic（運(yùn)行時(shí)恐慌）。當(dāng)程序發(fā)生panic時(shí)，程序會(huì)執(zhí)行當(dāng)前棧中的defer 函數(shù)列表。然后打印引發(fā)panic的具體信息，最后進(jìn)程退出，本篇文章我們一起探討Golang中的panic以及如何利用defer 和 recover 來恢復(fù)這種致命的異常

分析造成panic堆棧信息

func main() {
?? ?f1()
?? ?fmt.Println("main func end")
}

func f1() {
?? ?fmt.Println("func f1 start")
?? ?arr := []int{}
?? ?fmt.Println(arr[10])
?? ?fmt.Println("func f1 end")
}

上述代碼中，我在main函數(shù)(主協(xié)程)中調(diào)用了f1函數(shù)，在調(diào)用完該函數(shù)后，我打印了「main func end」,程序如果正常執(zhí)行的話會(huì)輸出

func f1 start
func f1 end
main func end

很明顯我們可以看出 f1 函數(shù)中，切片arr是沒有索引為10的元素的，這個(gè)時(shí)候程序運(yùn)行時(shí)會(huì)造成panic，下面是程序panic時(shí)，console打印的堆棧信息

func f1 start
panic: runtime error: index out of range [10] with length 0
goroutine 1 [running]:
main.f1()
/Users/carlos/go/src/test/demo01.go:15 +0x78
main.main()
/Users/carlos/go/src/test/demo01.go:8 +0x20
Process finished with the exit code 2

我們從堆棧中可以發(fā)現(xiàn)：

程序會(huì)在造成panic所處的位置終止

我們可以看到錯(cuò)誤信息中只輸出了 func f1 start

產(chǎn)生panic的原因

panic: runtime error: index out of range [10] with length 0

是哪里造成的panic

goroutine 1 [running] // 運(yùn)行該程序的協(xié)程
main.f1()
/Users/carlos/go/src/test/demo01.go:15 +0x78 // f1 函數(shù)，當(dāng)前demo01文件的低15行
main.main()
/Users/carlos/go/src/test/demo01.go:8 +0x20 // main 函數(shù)，當(dāng)前文件的弟8行

從上面的panic詳情我們可以看出，錯(cuò)誤鏈?zhǔn)峭ㄟ^棧的形式展現(xiàn)出來的（mian函數(shù)先調(diào)用，然后在mian中調(diào)用f1）,所以大家以后在程序發(fā)生panic時(shí)查看堆棧信息時(shí)可以先看最上層的錯(cuò)誤，因?yàn)檫@里是造成panic的根本原因

如何恢復(fù)panic造成的程序崩潰

Golang中提供了recover函數(shù)用來恢復(fù)因panic造成的程序崩潰。recover函數(shù)有一個(gè)返回值來告訴我們panic產(chǎn)生的具體原因。下面我們通過代碼來進(jìn)行演示

func main() {
?? ?f1()
?? ?r := recover()
?? ?fmt.Printf("%s \n", r)
?? ?fmt.Println("main func end")
}

func f1() {
?? ?fmt.Println("func f1 start")
?? ?arr := []int{}
?? ?fmt.Println(arr[10])
?? ?fmt.Println("func f1 end")
}

上述代碼中我只是在調(diào)用f1函數(shù)的下一行調(diào)用了recover函數(shù)，這樣一來我們的理想狀態(tài)了能夠恢復(fù)程序，讓程序執(zhí)行完main函數(shù)中剩下的代碼（打印panic信息，最后打印 main func end）,當(dāng)我們運(yùn)行該程序的時(shí)候發(fā)現(xiàn)recover并沒有起到作用,這是因?yàn)楫?dāng)f1造成panic時(shí)，f1下方的recover函數(shù)根本沒有機(jī)會(huì)執(zhí)行。

下面我將上述代碼進(jìn)行一個(gè)簡(jiǎn)單的改造：

func main() {
?? ?defer func() {
?? ??? ?fmt.Println("defer func start")
?? ??? ?if r := recover(); r != nil {
?? ??? ??? ?fmt.Printf("%s \n", r)
?? ??? ?}
?? ??? ?fmt.Println("defer func end")
?? ?}()
?? ?f1()
?? ?fmt.Println("main func end")
}

func f1() {
?? ?fmt.Println("func f1 start")
?? ?arr := []int{}
?? ?fmt.Println(arr[10])
?? ?fmt.Println("func f1 end")
}

輸出

func f1 start
defer func start
runtime error: index out of range [10] with length 0 
defer func end

上述代碼中，我只是在main函數(shù)最開頭添加了一個(gè)defer 函數(shù)，并在該函數(shù)中調(diào)用了recover函數(shù)。注意，我們?cè)谖恼碌淖铋_頭已經(jīng)說明了，當(dāng)程序發(fā)生panic時(shí)，程序會(huì)依次執(zhí)行棧中的defer函數(shù)（關(guān)于defer函數(shù)請(qǐng)閱讀官網(wǎng)描述）。所以當(dāng)前程序發(fā)生panic時(shí)在進(jìn)程退出之前會(huì)走到defer函數(shù)中執(zhí)行recover函數(shù)，recover函數(shù)會(huì)恢復(fù)當(dāng)前進(jìn)程并打印錯(cuò)誤信息。

這里我需要特別提醒你一點(diǎn)，最好將defer語句寫在函數(shù)的最前面。如果上述例子我將f1的調(diào)用寫在defer函數(shù)之前，你會(huì)發(fā)現(xiàn)recover函數(shù)還是沒有執(zhí)行

func main() {
?? ?f1()
?? ?defer func() {
?? ??? ?fmt.Println("defer func start")
?? ??? ?if r := recover(); r != nil {
?? ??? ??? ?fmt.Printf("%s \n", r)
?? ??? ?}
?? ??? ?fmt.Println("defer func end")
?? ?}()
?? ?fmt.Println("main func end")
}

這是因?yàn)閒1造成panic時(shí)，defer函數(shù)根本就沒有壓入函數(shù)調(diào)用棧中。

何時(shí)使用panic

當(dāng)你的項(xiàng)目中特別依賴一些組件時(shí)，比如一些web項(xiàng)目中經(jīng)常會(huì)在進(jìn)程啟動(dòng)之前初始化一些mysql，mq句柄。這些實(shí)例對(duì)業(yè)務(wù)來說是非常重要的，所以當(dāng)這些實(shí)例初始化失敗時(shí)我們可以直接讓當(dāng)前程序panic（手動(dòng)panic），然后及時(shí)發(fā)現(xiàn)問題并解決。這樣總比你帶著問題上線后，然后一批流入打入進(jìn)來，客戶端瘋狂報(bào)錯(cuò)要好

Golang中手動(dòng)調(diào)用panic：

func main() {
?? ?initMysql()
}

func initMysql() {
?? ?panic("init mysql failed") // panic可以接收一個(gè)interface類型的參數(shù)
}

到此這篇關(guān)于Golang中panic的異常處理的文章就介紹到這了,更多相關(guān)Golang panic內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論