乐趣区

关于后端:Go121-速览骚操作-panicnil-将成为历史以后别这么干了

大家好,我是煎鱼。

在 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/blog 已收录,学习 Go 语言能够看 Go 学习地图和路线,欢送 Star 催更。

Go 图书系列

  • Go 语言入门系列:初探 Go 我的项目实战
  • Go 语言编程之旅:深刻用 Go 做我的项目
  • Go 语言设计哲学:理解 Go 的为什么和设计思考
  • Go 语言进阶之旅:进一步深刻 Go 源码

举荐浏览

  • 写在 2023 年初的后端社招面试经验(四年教训):字节 米哈游 富途 猿辅导
  • Go 的一些乏味数据:中国最多人用、开发者年老;PHP 显著下滑的趋势
  • 疾速上手 Go CGO,把握在 Go 里写 C!
退出移动版