Go 标准库的一个设计败笔：哨兵错误

大家好，我是煎鱼。

在 Go 的历史发展中，总是有或多或少的坑。最近遇到一个跟错误类型定义和声明使用有关的小坑。

翻了一圈 Go 社区里的争论，发现又是一个暂时无法解决的未解之坑。今天分享给大家，平时开发时也可以给自己避避坑。

快速背景

在 Go 里有一种错误类型的定义，官方叫做哨兵错误（Sentinel errors）：

哨兵错误，常用于在程序中与全局变量的值对比。

可以参考最常见的 os 标准库，Go 官方自己在标准库内就是如此定义。

如下代码：

package os
...

var (
    ErrInvalid = fs.ErrInvalid // "invalid argument"
    ErrPermission = fs.ErrPermission // "permission denied"
    ErrExist      = fs.ErrExist      // "file already exists"
    ErrNotExist   = fs.ErrNotExist   // "file does not exist"
    ErrClosed     = fs.ErrClosed     // "file already closed"

这种写法有个非常大的问题，这些全局变量可以被被用户直接进行重新赋值和分配，破坏掉原有的值。

如下 “暴力” 代码：

// 脑子进煎鱼了
package main

import (
    "fmt"
    "os"
)

func main() {
    var nilFile *os.File

    // 原本的运行结果：prints 0, error("invalid argument")
    fmt.Println(nilFile.Read(nil))

    // 破坏这个哨兵错误的值，以便于后面引发问题
    os.ErrInvalid = nil

    // 由于重新设置值后，绕过了内部错误检查而导致程序出问题
    fmt.Println(nilFile.Read(nil))
}

这要是谁在程序里一个不小心变更或者埋个坑，那就真的是很莫名其妙了。排查的时候估计也很难受。

社区建议

用常量定义错误

于是社区里有个小伙伴 @myaaaaaaaaa 就提出了一个新的方案，将错误类型用常量重新定义，改造一下，希望能够解决这个问题。

用常量类型改造，如下代码：

package os

type osError string

func (err osError) Error() string {
    return string(err)
}

const (
    ErrInvalid    = osError("invalid argument")
    ErrPermission = osError("permission denied")
    ErrExist      = osError("file already exists")
    ErrNotExist   = osError("file does not exist")
    ErrClosed     = osError("file already closed")
)

常量不能重新赋值，可以解决前面提到的 var 定义的全局变量被用户乱改，进而影响标准库内程序运行的情况。

用结构体类型定义错误

进而也有 @Jorropo 提出了用结构体类型来解决这个问题会更好一些。

如下代码：

type errInvalid struct{}

func (errInvalid) Error() string {
    return "invalid argument"
}

type errPermission struct{}

func (errPermission) Error() string {
    return "permission denied"
}

type errExist struct{}

func (errExist) Error() string {
    return "file already exists"
}

type errNotExist struct{}

func (errNotExist) Error() string {
    return "file does not exist"
}

type errClosed struct{}

func (errClosed) Error() string {
    return "file already closed"
}

var (
    ErrInvalid    errInvalid
    ErrPermission errPermission
    ErrExist      errExist
    ErrNotExist   errNotExist
    ErrClosed     errClosed
)

官方答复

Go 核心团队成员 @Ian Lance Taylor 表示：“谢谢，这是个好主意。但我们现在不能做这样的改动，因为这会破坏 Go1 的兼容性保证”

千言万语，标准的好人卡。

总结

这在 Go 里算是一个或大或小的 “难言之隐”，因为 Go 核心团队是经常在一些设计领域上是标榜要较为严格和显式的，但是在错误定义这块早期就翻了个车。

同时确实是变更写法的话，会明显违反 Go1 兼容性保障，这相当于是手心手背都是肉了。兼容性，有好有坏。

这问题最早在几年前撕泛型设计时我就见过了。期望未来也基于 rsc 延伸的向前向后的兼容性扩展来灵活应对这个问题了。

文章持续更新，可以微信搜【脑子进煎鱼了】阅读，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言可以看 Go 学习地图和路线，欢迎 Star 催更。

推荐阅读

• Go 是 Google 的语言？ 核心成员的内部视角
• 创始人 Rob Pike：Go 做对了什么，才能如此成功？
• Go 泛型有没有可能在后期改为 <> 尖括号？