这个新 Go 错误处理提案，能解决问题不？

大家好，个新我是错误处理煎鱼。

Go 语言的提案题一大特色就是它的错误机制，因此基本上所有的决问错误处理提案或讨论我都会有所查看和学习，开拓不同的个新思考视野和解决方法。

今天分享的错误处理是 @Cristo García[1] 所提出的提案《Simple Error Handling for Go 2[2]》，略有修改，提案题和煎鱼一起学习和讨论吧！决问

Go 必须仍然是个新 Go

这一个提案的核心观点是 Go 必须仍然是 Go，这意味着对于错误处理的错误处理改造需要满足如下原则：

增加尽可能少的语法。

尽可能明确方便。提案题本文中的决问 “我“ 均指代提案作者 @Cristo García，并非正在学习的个新煎鱼。原想法

原提案作者 @PeterRk 提出了以下思想：

func getDivisorFromDB(key string) (uint,错误处理 error) {

//...

}

func GetDivisor(key string) (uint, error) {

exit := func(err error) (uint, error) {

return 1, fmt.Errorf("fail to get divisor with key \"%s\": %v", key, err)

}

divisor := check(getDivisorFromDB(key), exit)

//...

return divisor, nil

}

使用示例：

divisor := check(getDivisorFromDB(key), exit)

等同于现有的：

divisor, err := getDivisorFromDB(key)

if err != nil {

return exit(err) //return err

}

注意看 check 函数，第二个参数的提案题 exit 函数是云南idc服务商它 if err != nil 后的回调方法，用于出现 err 时的错误处理。

提案作者认为这是一个正确的方向，我们可以改进它（言外之意：现在的还不够好）。

问题是什么

原有的这个想法，有如下两个问题：

包含不明确的返回语句。有时抽象是不必要的，并且使代码更难阅读。新想法

为此新的想法需要解决以上两个问题，@Cristo García 期望达到更好的效果。通过对语法的简单修改，我们新增 or 关键字。

可以得到以下示例：

divisor, err := getDivisorFromDB(key) or return exit(err)

新增加的 or 关键字将会检测最后返回的值（必须是错误类型）是否与 nil 不同。若不同，将执行右边的函数。源码库

我们也可以省略 return，代码将继续执行。它将像在常规 Go 代码中一样被丢弃，这样该函数就更可重用。

如下示例：

func GetDivisor(key string) (divisor uint, err error) {

divisor, err = getDivisorFromDB(key) or return

return

}

也就是 or return 语句后不跟任何东西，是可以的，会默认抛弃掉。

特殊场景：defer

本节只是为了辩论，但我们可以借此机会为 defer 添加错误检查，看看能不能做一些什么，得到新的处理方式。

核心思路：如果我们能不把返回的错误保存在一个变量中，并在 defer 中使之或得到触发，那么会非常的有意思。

如下示例 1：

defer f.Close() or return errHdl("", fmt.Errorf("couldnt close file"))

不主动显式声明变量，若返回值是错误类型且不等于 nil，则自动调用 or return 右侧的函数并进行处理。

如下示例 2：

defer err := f.Close() or return errHdl("couldnt close file", err)

定义接受错误的变量 err 变量，能通过 or return 的语法直接传参进入函数 errHdl 的入参中被使用。

结果

新增了新的 or return 语法后再与原有的香港云服务器错误处理机制进行对比，看看如何。

新的：

func Foo(path string) ([]byte, error) {

errHdlr := func(reason string, err error) ([]byte, error) {

return nil, fmt.Errorf("foo %s %w", reason, err)

}

f, err := os.Open(path) or return errHdlr("couldnt open file", err)

defer f.Close() or return errHdl("", fmt.Errorf("couldnt close file"))

result, err := io.ReadAll(f) or return errHdlr("couldnt read from file " + path, err)

return result, nil

}

旧的：

func Foo(path string) ([]byte, error) {

f, err := os.Open(path)

if err != nil {

return nil, fmt.Errorf("foo %s %w", "couldnt open file", err)

}

result, err := io.ReadAll(f)

if err != nil {

return nil, fmt.Errorf("foo %s %w", "couldnt read from file " + path, err)

}

err = f.Close()

if err != nil {

return nil, fmt.Errorf("foo %s %w", "couldnt close the file " + path, err)

}

return result, nil

}

这是一个非常简单的例子，但我们已经可以看到其好处。正在阅读代码的程序员甚至可以把注意力放在左边而忽略错误处理。

在使用 gofmt 格式化代码后，也比较美观。

如下示例：

f, err := os.Open(path) or return errHdlr("couldnt open file", err)

defer f.Close() or return errHdl("", fmt.Errorf("couldnt close file"))

result, err := io.ReadAll(f) or return errHdlr("couldnt read from file " + path, err)

对的很齐。

总结

在这一个新提案中，作者正在做意见征集的阶段。其主要是推行了 or 关键字和变量可传递至右侧函数等多种思路（前段时间我还分享了个左侧函数和表达式的提案）。

该作者的目的是想尽可能的方便，并且不写以往被大家吐槽的 if err != nil，实现更加的简洁。

你觉得这个提案怎么样呢？欢迎在评论区交流和讨论。

参考资料

[1]Cristo García: https://gist.github.com/GGCristo

[2]Simple Error Handling for Go 2: https://gist.github.com/GGCristo/27c33308a07c1be216542f1005792c2b

很赞哦!（73）