关于后端: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 个小时来排查：

还是有些费解的，不遇到的还真不肯定晓得。

这在 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 源码

写在 2023 年初的后端社招面试经验（四年教训）：字节米哈游富途猿辅导
Go 的一些乏味数据：中国最多人用、开发者年老；PHP 显著下滑的趋势
疾速上手 Go CGO，把握在 Go 里写 C！

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

费解的雷

修复 panic(nil)

总结

Go 图书系列

举荐浏览