咱们好,我是煎鱼。
在 Go 言语中,回来过错、抛出反常一直是咱们比较重视的话题。在抛出反常上,咱们一般都是这么用的:
func mayPanic() {
panic("脑子进煎鱼了")
}
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered. Error:\n", r)
return
}
fmt.Println("煎鱼进脑子了")
}()
mayPanic()
fmt.Println("After mayPanic()")
}
运转成果:
Recovered. Error:
脑子进煎鱼了
这看起来一切正常,没什么问题的样子。
隐晦的雷
其实在现在的 Go 版别有一个较隐晦的雷。看看 panic 和 recover 对应的参数和回来类型。如下:
func panic(v interface{})
func recover() interface{}
参数值类型是 interface
,也就意味着能够传任何值。那咱们传 nil 给 panic 行不行呢?
如下代码:
func mayPanic() {
panic(nil)
}
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered. Error:\n", r)
return
}
fmt.Println("煎鱼进脑子了")
}()
mayPanic()
fmt.Println("After mayPanic()")
}
再看一下输出成果,你以为是什么?
运转成果:煎鱼进脑子了。
尽管的确调用 panic(nil)
往里传了 nil 值。这成果说对如同也对,说不对如同也很怪?
因为咱们触发了反常(panic),便是希望程序抛出反常,但却因为入参 “阴差阳错” 是 nil,这个应用程序就按正常逻辑走的。这显着和 panic 的语法特性预期不相符。
甚至社区有反应,因为这一个坑,他们团队花了 3 个小时来排查:
仍是有些隐晦的,不遇到的还真不必定知道。
修正 panic(nil)
这在 2018 年由 Go 的核心成员@ Brad Fitzpatrick 提出了《spec: guarantee non-nil return value from recover》期望得到解决。
如下图:
其以为 panic(nil)
现在的处理是不正确的,应该要回来 runtime 过错,类似 runtime.NilPanic 的一个特别类型。
通过 4-5 年的社区讨论、放置、纠结、处理后,将会在 Go1.21 起正式提供一个 PanicNilError 的新过错类型,用于替换和修正 panic(nil)
的场景。
PanicNilError 类型定义如下:
// A PanicNilError happens when code calls panic(nil).
//
// Before Go 1.21, programs that called panic(nil) observed recover returning nil.
// Starting in Go 1.21, programs that call panic(nil) observe recover returning a *PanicNilError.
// Programs can change back to the old behavior by setting GODEBUG=panicnil=1.
type PanicNilError struct {
// This field makes PanicNilError structurally different from
// any other struct in this package, and the _ makes it different
// from any struct in other packages too.
// This avoids any accidental conversions being possible
// between this struct and some other struct sharing the same fields,
// like happened in go.dev/issue/56603.
_ [0]*PanicNilError
}
func (*PanicNilError) Error() string { return "panic called with nil argument" }
func (*PanicNilError) RuntimeError() {}
在新版别中,Go 应用程序调用 panic(nil)
将会在 Go 编译器中被替换成 panic(new(runtime.PanicNilError))
,这一动作改变 Go1.20 及以前的行为。
在 Go1.21 起,调用 panic(nil)
的运转成果会变成:
panicked: panic called with nil argument
由于这一行为自身是损坏 Go1 兼容性保障的,因此 Go 团队提供了兼容措施,在 Go 编译时新增 GODEBUG=panicnil=1
标识,就能够确保与老版别行为一致。
总结
在 Go 言语中,panic
关键字自身的方针便是抛出反常,但早期规划上呈现了必定的疏忽,运用 nil 能够让应用程序持续正常运转。
这也算一个比较常见的点了,和平时写业务代码相同。要确保边界值和特别值的判断,这样才干确保代码的健壮性和反常处理与预期保持一致。
文章持续更新,能够微信搜【脑子进煎鱼了】阅览,本文 GitHub github.com/eddycjy/blo… 已录入,学习 Go 言语能够看 Go 学习地图和道路,欢迎 Star 催更。
Go 图书系列
- Go 言语入门系列:初探 Go 项目实战
- Go 言语编程之旅:深化用 Go 做项目
- Go 言语规划哲学:了解 Go 的为什么和规划思考
- Go 言语进阶之旅:进一步深化 Go 源码