用 panic-recover 做錯誤處理？會影響 Go 程序性能的
Go 這一門編程語音的 if err != nil 錯誤處理機制一直飽受爭議。既然爭議那么多，想必有很多人想出各種奇思妙計，試圖解決這個問題。
其中一個辦法是使用 panic-recover 來替代 if err != nil 來做錯誤處理機制。
對于 Go 應用來講，這種方式也是有一定的損耗。今天結合在網上看到的 The cost of Go’s panic and recover 和大家一起來看看。
Effective Java 例子
原作者 @Julien Cretel 是在閱讀經典作品《Effective Java》中學習時，看到 Java 異常進行控制流的示例：
try {
int i = 0;
while (true)
range[i++].climb();
} catch (ArrayIndexOutOfBoundsException e) {
}該程序的變量 i 最終會遞增到數組的長度，此時如果試圖訪問索引 i 處的數組，就會引發 ArrayIndexOutOfBoundsException 異常，該異常會被捕獲并立即忽略。
使用 panic/recover 做控制流
很多 Java、PHP 等其他很多編程語言轉過來的同學，第一次接觸 Go 時，會試圖像上述例子去尋找能做一定的 try-catch 錯誤處理機制的例子。
而在 Go 這一門編程語言中，能做到的類似模式的只有 panic-recover 的機制，因此可能產生了一些濫用的情況。
下述是模擬 Java try-catch 示例粗略翻譯成 Go panic-recover 示例的演示，以此驗證性能基準的測試。
1、主程序：
package main
type Mountain struct {
climbed bool
}
func (m *Mountain) Climb() {
m.climbed = true
}
func main() {
mountains := make([]Mountain, 8)
ClimbAllPanicRecover(mountains)
}
func ClimbAllPanicRecover(mountains []Mountain) {
deferfunc() {
recover()
}()
for i := 0; ; i++ {
mountains[i].Climb()
}
}
func ClimbAll(mountains []Mountain) {
for i := range mountains {
mountains[i].Climb()
}
}2、基準測試：
package main
import (
"fmt"
"testing"
)
var cases [][]Mountain
func init() {
for _, size := range []int{0, 1, 1e1, 1e2, 1e3, 1e4, 1e5} {
s := make([]Mountain, size)
cases = append(cases, s)
}
}
func BenchmarkClimbAll(b *testing.B) {
benchmark(b, "idiomatic", ClimbAll)
benchmark(b, "panic-recover", ClimbAllPanicRecover)
}
func benchmark(b *testing.B, impl string, climbAll func([]Mountain)) {
for _, ns := range cases {
f := func(b *testing.B) {
b.ReportAllocs()
for b.Loop() {
climbAll(ns)
}
}
desc := fmt.Sprintf("impl=%s/size=%d", impl, len(ns))
b.Run(desc, f)
}
}測試結果
從測試結果可以得知，即使是在處理小規模輸入切片時，ClimbAllPanicRecover 的性能也明顯劣于 ClimbAll 的實現。
如下測試報告：
? demo1 benchstat -col '/impl@(idiomatic panic-recover)' results.txt
goos: darwin
goarch: arm64
pkg: example.com/greet
cpu: Apple M3 Pro
│ idiomatic │ panic-recover │
│ sec/op │ sec/op vs base │
ClimbAll/size=0-11 1.046n ± 32% 94.320n ± 0% +8921.52% (p=0.000 n=10)
ClimbAll/size=1-11 1.612n ± 20% 94.400n ± 0% +5754.26% (p=0.000 n=10)
ClimbAll/size=10-11 4.202n ± 6% 97.565n ± 0% +2221.87% (p=0.000 n=10)
ClimbAll/size=100-11 26.69n ± 0% 120.20n ± 0% +350.36% (p=0.000 n=10)
ClimbAll/size=1000-11 255.0n ± 0% 354.8n ± 2% +39.14% (p=0.000 n=10)
ClimbAll/size=10000-11 2.479μ ± 0% 2.595μ ± 0% +4.68% (p=0.000 n=10)
ClimbAll/size=100000-11 24.72μ ± 0% 24.87μ ± 0% +0.61% (p=0.001 n=10)
geomean 60.46n 422.2n +598.25%
│ idiomatic │ panic-recover │
│ B/op │ B/op vs base │
ClimbAll/size=0-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=1-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=10-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=100-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=1000-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=10000-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=100000-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
geomean 1 24.00 ?
1 summaries must be >0 to compute geomean
│ idiomatic │ panic-recover │
│ allocs/op │ allocs/op vs base │
ClimbAll/size=0-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=1-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=10-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=100-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=1000-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=10000-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=100000-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
geomean 1 1.000 ?
1 summaries must be >0 to compute geomean具體差異體現在：
- 執行效率差距：在小數據集場景下，panic/recover 的操作成本占據主導地位，導致 ClimbAllPanicRecover 運行遲緩。在 64 位系統中，每次調用會產生 24 字節的堆內存分配（推測源于運行時觸發的 runtime.boundsError 邊界錯誤）。
- 內存管理差異：標準實現 ClimbAll 完全避免了內存分配，因此不會對垃圾回收機制造成額外壓力。
- 性能趨勢變化：隨著輸入切片長度的增加，兩種實現的性能差異逐漸縮小。這是因為 panic-recover 的固定開銷被更大的計算量所稀釋，不再成為主要性能瓶頸。
為什么 Go 不支持 try-catch
Go 官方早在《Error Handling — Problem Overview[1]》提案早已明確提過，Go 官方在設計上會有意識地選擇使用顯式錯誤結果和顯式錯誤檢查。
結合《language: Go 2: error handling meta issue[2]》可得知，要拒絕 try-catch 關鍵字的主要原因是：
- 會涉及到額外的流程控制，因為使用 try 的復雜表達式，會導致函數意外返回。
- 在表達式層面上沒有流程控制結構，只有 panic 關鍵字，它不只是從一個函數返回。
說白了，就是設計理念不合，加之實現上也不大合理。在以往的多輪討論中早已被 Go 團隊拒絕了。
反之 Go 團隊倒是一遍遍在回答這個問題，已經不大耐煩了，直接都整理了 issues 版的 FAQ 了。
圖片
總結
對于 Go 這一門編程語言來講，if err != nil 是其提供的最基本的錯誤處理機制。
雖然很多開發同學略感不適，但官方依然是建議在其基礎上做設計模式的設計和調整。這是較為推薦的。
在很多妙計中，也有像本文使用 panic-recover 的方式。但通過實際測試來講，是會明確影響性能的。
官方也明確過不推薦該類錯誤處理機制的方式。
見仁見智了。
參考資料
[1] Error Handling — Problem Overview: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
[2] language: Go 2: error handling meta issue: https://github.com/golang/go/issues/40432
