文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

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

2024-12-01 18:43

关注

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

今天分享的是 @Cristo García[1] 所提出的提案《Simple Error Handling for Go 2[2]》,略有修改,和煎鱼一起学习和讨论吧!

Go 必须仍然是 Go

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

增加尽可能少的语法。

原想法

原提案作者 @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 函数是它 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("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,实现更加的简洁。

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

参考资料

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

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

来源:脑子进煎鱼了内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯