建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是煎魚。
十多年的銀州網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整銀州建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)建站從事“銀州網(wǎng)站設(shè)計(jì)”,“銀州網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
在我們學(xué)習(xí)和平時(shí)使用 Go 時(shí)，一定會(huì)涉及到一個(gè)內(nèi)置函數(shù) panic：
func panic(v any)調(diào)用該函數(shù)后會(huì)停止代碼的控制流程并開始恐慌，達(dá)到扭轉(zhuǎn)當(dāng)前程序控制流的目的。在使用上也常常和 defer 和 recover 關(guān)聯(lián)上。
快速 Demo
以下是一個(gè)簡(jiǎn)單的使用 Demo：
func main() {
panic("腦子進(jìn)煎魚了")
_, err := os.Create("/tmp/file")
if err != nil {
log.Fatalln(err)
}
}輸出結(jié)果：
$ go run demo.go
panic: 腦子進(jìn)煎魚了
goroutine 1 [running]:
main.main()
/Users/eddycjy/demo.go:10 +0x25
exit status 2看著都沒什么問題。輸出結(jié)果符合預(yù)期。
一點(diǎn)爭(zhēng)議
由于 Go 起協(xié)程（goroutine）非常簡(jiǎn)單、方便，因此絕大部分開發(fā)者在應(yīng)用程序中會(huì)經(jīng)常用 goroutine 去做各種并發(fā)處理的邏輯，一看不小心。就很有可能會(huì)引發(fā)程序中的 panic，導(dǎo)致整個(gè)應(yīng)該程序崩潰，出現(xiàn)事故。（見過好幾起低級(jí)錯(cuò)誤了，覺得程序沒問題，所以也沒有主動(dòng)加防御性代碼）
有一個(gè)比較常見觸發(fā)的場(chǎng)景之一：空指針調(diào)用。時(shí)不時(shí)就能見到幾個(gè)應(yīng)用又誘發(fā)了。
如下代碼：
type T struct {
Name string
}
func main() {
var user *T
go func() {
// 異步執(zhí)行一些業(yè)務(wù)流程，不小心 panic 了...
fmt.Println(user.Name)
}()
// 做一些事情...
time.Sleep(time.Second * 1)
fmt.Println("腦子進(jìn)煎魚了")
}輸出結(jié)果：
$ go run demo.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x1087178]
goroutine 6 [running]:
main.main.func1()
/Users/eddycjy/demo.go:16 +0x18
created by main.main in goroutine 1
/Users/eddycjy/demo.go:14 +0x31
exit status 2當(dāng)然，這也是有辦法解決的。標(biāo)準(zhǔn)的方式是通過 recover，捕獲 panic。如下代碼：
go func() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered in f", r)
}
}()
// 異步執(zhí)行一些業(yè)務(wù)流程，不小心 panic 了...
fmt.Println(user.Name)
}()輸出結(jié)果：
Recovered in f runtime error: invalid memory address or nil pointer dereference
腦子進(jìn)煎魚了又或是基于 goroutine+recvoer 封裝一個(gè)協(xié)程調(diào)用的方法。要求使用這類工具庫來規(guī)避這個(gè) “坑”。
但不得不說，很多同學(xué)崩就崩在不覺得這個(gè)地方會(huì)出問題，但就是有問題。最后只能一溜煙全都用封裝好的工具庫來起 goroutine 了。
新提案：可定義 panic 錯(cuò)誤信息
在前面的案例中，我們可以看到 panic 后現(xiàn)在的輸出信息如下：
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x1087178]
goroutine 6 [running]:
main.main.func1()
/Users/eddycjy/demo.go:16 +0x18
created by main.main in goroutine 1
/Users/eddycjy/demo.go:14 +0x31
exit status 2程序輸出了恐慌值和 goroutine 堆棧跟蹤。
這第一眼看起來是非常迷惑的，要看錯(cuò)誤信息。如果是程序內(nèi)拋的空指針，還要去翻堆棧信息去猜，再看是哪里的程序。做一輪排查、定位、驗(yàn)證。
因此社區(qū)里 @Mitar 提出了《proposal: runtime: provide a way to format output in unhandled panics[1]》的提案。希望可以針對(duì)意外情況+無人處理的 panic 錯(cuò)誤進(jìn)行自定義的格式化處理。
提案中希望 panic 新增 PanicError：
type panicError interface {
error
PanicError() string
}如果值實(shí)現(xiàn)了該接口，在 panic 時(shí)則會(huì)優(yōu)先調(diào)用 PanicError 方法，為錯(cuò)誤處理提供一個(gè)可選選項(xiàng)，可以為調(diào)試補(bǔ)充額外的有用信息。
這樣就可以進(jìn)一步區(qū)分出 Panic 錯(cuò)誤和普通 Error 錯(cuò)誤的方法，并且針對(duì) Panic 的錯(cuò)誤做各種奇怪的操作和補(bǔ)充。
總結(jié)
今天給大家分享了社區(qū)對(duì)于 panic 優(yōu)化的一個(gè)小點(diǎn)。原提案作者的目的是為了針對(duì) panic 錯(cuò)誤新增 PanicError 方法，若存在則優(yōu)先使用該方法，而非與普通 error 共用 Error 方法，并以此去做好區(qū)分識(shí)別和實(shí)現(xiàn)。
在 Go 中對(duì) panic 的優(yōu)化，官方一直都是比較遲緩的。一方面是大佬們比較少寫業(yè)務(wù)代碼，另外一方面是類似對(duì) panic 加全局?jǐn)r截器避免崩潰等方式，也比較違背開創(chuàng)語言時(shí)的哲學(xué)宗旨。
文章名稱：新提案：Gopanic能不能加個(gè)PanicError？
轉(zhuǎn)載注明：http://www.5511xx.com/article/dpgdsoc.html
