共计 2796 个字符，预计需要花费 7 分钟才能阅读完成。
大家好，我是煎鱼。
Go 语言的一大特色就是它的谬误机制，因而基本上所有的错误处理提案或探讨我都会有所查看和学习，开辟不同的思考视线和解决办法。
明天分享的是 @Cristo García 所提出的提案《Simple Error Handling for Go 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
}提案作者认为这是一个正确的方向，咱们能够改良它（话中有话：当初的还不够好）。
问题是什么
原有的这个想法，有如下两个问题：
- 蕴含不明确的返回语句。
- 有时形象是不必要的，并且使代码更难浏览。
新想法
为此新的想法须要解决以上两个问题，@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("couldn't close file"))不被动显式申明变量，若返回值是谬误类型且不等于 nil，则主动调用 or return 右侧的函数并进行解决。
如下示例 2：
defer err := f.Close() or return errHdl("couldn't 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("couldn't open file", err)
defer f.Close() or return errHdl("", fmt.Errorf("couldn't close file"))
result, err := io.ReadAll(f) or return errHdlr("couldn't 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", "couldn't open file", err)
}
result, err := io.ReadAll(f)
if err != nil {return nil, fmt.Errorf("foo %s %w", "couldn't read from file " + path, err)
}
err = f.Close()
if err != nil {return nil, fmt.Errorf("foo %s %w", "couldn't close the file " + path, err)
}
return result, nil
}这是一个非常简单的例子，但咱们曾经能够看到其益处。正在浏览代码的程序员甚至能够把注意力放在右边而疏忽错误处理。
在应用 gofmt 格式化代码后，也比拟好看。
如下示例：
f, err := os.Open(path) or return errHdlr("couldn't open file", err)
defer f.Close() or return errHdl("", fmt.Errorf("couldn't close file"))
result, err := io.ReadAll(f) or return errHdlr("couldn't read from file " + path, err)对的很齐。
总结
在这一个新提案中，作者正在做意见征集的阶段。其次要是推广了 or 关键字和变量可传递至右侧函数等多种思路（前段时间我还分享了个左侧函数和表达式的提案）。
该作者的目标是想尽可能的不便，并且不写以往被大家吐槽的 if err != nil，实现更加的简洁。
你感觉这个提案怎么样呢？欢送在评论区交换和探讨。
文章继续更新，能够微信搜【脑子进煎鱼了】浏览，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言能够看 Go 学习地图和路线，欢送 Star 催更。
Go 图书系列
- Go 语言入门系列：初探 Go 我的项目实战
- Go 语言编程之旅：深刻用 Go 做我的项目
- Go 语言设计哲学：理解 Go 的为什么和设计思考
- Go 语言进阶之旅：进一步深刻 Go 源码
更多浏览
- Go 想要加个箭头语法，这下更像 PHP 了！
- Go 错误处理新思路？用左侧函数和表达式