新提案：Go panic 能不能加個 PanicError？
大家好，我是煎魚。
在我們學習和平時使用 Go 時，一定會涉及到一個內置函數 panic：
func panic(v any)調用該函數后會停止代碼的控制流程并開始恐慌，達到扭轉當前程序控制流的目的。在使用上也常常和 defer 和 recover 關聯上。
快速 Demo
以下是一個簡單的使用 Demo：
func main() {
panic("腦子進煎魚了")
_, err := os.Create("/tmp/file")
if err != nil {
log.Fatalln(err)
}
}輸出結果：
$ go run demo.go
panic: 腦子進煎魚了
goroutine 1 [running]:
main.main()
/Users/eddycjy/demo.go:10 +0x25
exit status 2看著都沒什么問題。輸出結果符合預期。
一點爭議
由于 Go 起協程（goroutine）非常簡單、方便，因此絕大部分開發者在應用程序中會經常用 goroutine 去做各種并發處理的邏輯，一看不小心。就很有可能會引發程序中的 panic，導致整個應該程序崩潰，出現事故。（見過好幾起低級錯誤了，覺得程序沒問題，所以也沒有主動加防御性代碼）
有一個比較常見觸發的場景之一：空指針調用。時不時就能見到幾個應用又誘發了。
如下代碼：
type T struct {
Name string
}
func main() {
var user *T
go func() {
// 異步執行一些業務流程，不小心 panic 了...
fmt.Println(user.Name)
}()
// 做一些事情...
time.Sleep(time.Second * 1)
fmt.Println("腦子進煎魚了")
}輸出結果：
$ 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當然，這也是有辦法解決的。標準的方式是通過 recover，捕獲 panic。如下代碼：
go func() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered in f", r)
}
}()
// 異步執行一些業務流程，不小心 panic 了...
fmt.Println(user.Name)
}()輸出結果：
Recovered in f runtime error: invalid memory address or nil pointer dereference
腦子進煎魚了又或是基于 goroutine+recvoer 封裝一個協程調用的方法。要求使用這類工具庫來規避這個 “坑”。
但不得不說，很多同學崩就崩在不覺得這個地方會出問題，但就是有問題。最后只能一溜煙全都用封裝好的工具庫來起 goroutine 了。
新提案：可定義 panic 錯誤信息
在前面的案例中，我們可以看到 panic 后現在的輸出信息如下：
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 堆棧跟蹤。
這第一眼看起來是非常迷惑的，要看錯誤信息。如果是程序內拋的空指針，還要去翻堆棧信息去猜，再看是哪里的程序。做一輪排查、定位、驗證。
因此社區里 @Mitar 提出了《proposal: runtime: provide a way to format output in unhandled panics[1]》的提案。希望可以針對意外情況+無人處理的 panic 錯誤進行自定義的格式化處理。
提案中希望 panic 新增 PanicError：
type panicError interface {
error
PanicError() string
}如果值實現了該接口，在 panic 時則會優先調用 PanicError 方法，為錯誤處理提供一個可選選項，可以為調試補充額外的有用信息。
這樣就可以進一步區分出 Panic 錯誤和普通 Error 錯誤的方法，并且針對 Panic 的錯誤做各種奇怪的操作和補充。
總結
今天給大家分享了社區對于 panic 優化的一個小點。原提案作者的目的是為了針對 panic 錯誤新增 PanicError 方法，若存在則優先使用該方法，而非與普通 error 共用 Error 方法，并以此去做好區分識別和實現。
在 Go 中對 panic 的優化，官方一直都是比較遲緩的。一方面是大佬們比較少寫業務代碼，另外一方面是類似對 panic 加全局攔截器避免崩潰等方式，也比較違背開創語言時的哲學宗旨。
