20 | 错误处理 （下）

作者回复: 这严格来说不是bug，这是Go语言原生的编程风格决定的。但我个人认为这是一个很不好的风格。 我刚刚又看了一下 Go 1.16 的源码（如 os 包、io/fs 包、internal/oserror 包、net 包、internal/poll 包等）。 我估计Go语言官方也早已意识到了这个问题，他们已经做了一些改进。大家如果有兴趣可以去看看。鉴于篇幅限制，我在这里只说 os.ErrClosed 吧。 这个 os.ErrClosed 的声明代码如下： var ErrClosed = fs.ErrClosed // "file already closed" 其中的 fs 指代的是 io/fs 包，该包有代码： var ErrClosed = errClosed() // "file already closed" func errClosed() error { return oserror.ErrClosed } 其中的 oserror 指代的是 internal/oserror.ErrClosed 包，该包中有代码： var ErrClosed = errors.New("file already closed") 也就是说，变量 os.ErrClosed 最终指向的是一个 internal（只有Go标准库的内部代码才能访问到的）值，即 internal/oserror.ErrClosed 变量的值 errors.New("file already closed") 。 这里为什么要绕这么一大圈呢？？实际上，为了保证Go语言标准库的向后兼容性，目前已经存在的这类原生风格的代码在当前是没办法完全修正的。例如，os.ErrClosed 的名字没法改变，一旦改变就破坏了向后兼容性，同时也没法把 os.ErrClosed 这个标识符指代的程序实体由变量改为函数，一旦改了照样破坏向后兼容性。在我看来，这着实有些尴尬。 既然解决不了问题，那Go语言官方为什么还要做出上述的改进呢？？我估计，这是在为以后的大改做准备。你看，一旦把暴露在外的 error 类型变量（如 os.ErrClosed）的初识值改为对一个 internal（只可内部访问的）值的引用，就完全可以在Go标准库的内部来判断该变量的值是否“依然是初始值”了。如果遇到恶意/意外修改，那么就有能力判断和恢复了。 虽然我还没在Go标准库的源码中看到这样的判断（也许是有的，然而我至此还没看到），但这终归是为进一步优化留了重要的口子。 不过，遗憾的是，由于它们最终引用到的是 internal 包中的变量，所以（在Go标准库外部的）我们的代码依然没有能力做上述判断和恢复。这依然有些尴尬。 所以，我在此呼吁大家，千万不要在自己的项目中遵从这样的原生风格（也就是，把错误变量的名称首字母大写）。我们可以这样做（参考代码如下）： var errClosed = errors.New("file already closed") // 变量名首字母小写，以防止来自包外的修改。 func ErrClosed() error { // 函数名首字母大写，以便来自包外的访问。 return errClosed // 总是返回同一个内部的错误值。 } 这样就可以完美避免掉包外代码对原有错误值的恶意/意外修改了，同时还不会影响到错误值的获取和判断。 或者，如果想以（包含了多个代码包的）某个模块为单位，那么可以把这类代表错误的变量都声明到这个模块的 internal 包中去，就像Go语言标准库做的那样。 好了，说了这么多，希望我说明白了。如果还有疑问，可以继续留言给我。

作者回复: 等稿子都赶完了，我会集中精力补图的。

作者回复: 意思是，这个字段可以容纳的值的类型是一个范围，而不是一个明确的类型。这就相当于给这个结构体的部分实现创造了动态替换的条件。 如果这个接口类型的结构体是匿名嵌入的，那么基本上是可以等价的。当然了，这种情况下，要保证这个字段是有值的，否则真正调用的时候会报错。

作者回复: 建议不要犯懒；） 光听我说没有太大意义。

作者回复: 好，下回再改进吧：）