Go 语言团队否决关于"try"语句的提案

局长
 局长
发布于 2019年07月20日
收藏 12

Go 语言作者之一 Robert Griesemer 前几天代表 Go 语言开发团队的提案审查委员会公布了关于否决一项提案的决定。Robert 在「内置的 Go 错误检查函数,"try"」提案下面的回复中发布了这个公告,并表示基于社区压倒性的反应和由此引起的广泛讨论,团队决定提前拒绝此项提案。

关于 Go 2 的错误处理问题,Robert 表示团队去年就已阐述了对此的看法,但当时并没引起足够的注意和讨论。所以关于"try"语句的提案可能是解决此问题的一个很好的解决方案,但对于大多数使用者而言,这可能没解决到什么问题。

下面举一个 try 语句的示例。

例如如下代码:

f, err := os.Open(filename)
if err != nil {
	return …, err  // zero values for other results, if any
}

可通过使用 try 语句简化为:

f := try(os.Open(filename))

可以看到,内置函数 try 采用一个单一表达式作为参数。表达式必须求出 n+1 个值(其中 n 可能为零),其中最后一个值必须是error类型。如果错误参数(final)为 nil,则返回前 n 个值(如果有),否则返回带有该错误的封闭函数。

这种方法最主要的缺点是需要对错误结果参数进行命名,为此可能会导致 API 不够美观。总而言之,一开始try看起来就有点不寻常,因为它只是针对一个特定任务量身定制的语法糖,使用较少的样板代码进行错误处理,并且能足够好地处理该任务。不过它非常符合 Go 的哲学 ——try不是为解决所有错误处理情况而设计的;它旨在很好地处理最常见的情况,以保持设计简单明了。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:Go 语言团队否决关于"try"语句的提案
加载中

精彩评论

OSC_IFVIqu
OSC_IFVIqu
不要随便误导。try的出现初衷是为了避免大量的返回值判断,有效减少代码量,提高代码流畅性和可读性。
kakai
kakai
都将逐步像java靠拢,java处理异常虽然啰嗦,但胜在务实。
独孤影
独孤影
干得漂亮,try个卵
NoneObject
NoneObject
兄弟,注意你很久了,起码一年多,发现你只要是有golang的新闻就会进来拉踩,搞的跟饭圈的人一样,知道你主推D语言也搞rust,但是真没必要捧rust的时候去猛踩golang,所以今天真想对你说几句,不同语言都有自己的优劣势,同样不同的人对不同编程语言的接受度和亲切度也不一样(这个亲切度主要是每个人的语言使用习惯,思维方式,语法顺眼度,标准库是否和心意决定的)。也许某个语言对你来时是蜜糖,但对别人来说是砒霜。编程语言只要使用者能发挥出其语言优势,编写出高质量的软件就好,没必要学饭圈的那套拉踩规则。每个人都会用自己的脚投票,选择适合自己的语言。请不要把饭圈的那套东西也带到编程的圈子,没意义。还有,你能不能成熟点?你这种心态怎么做开发,你这种心态也推广不了D语言和rust
OSC_DSbsEY
OSC_DSbsEY
try这东西完全没有必要,很多开发者都局限在现有编程语言中走不出来

最新评论(53

busgo
busgo
语言之争有必要争吗?喷子们
大賢者
大賢者
C语言就没有 try。
冰力
冰力
接上条 tidb:tidb 是非常优秀的分布式db,而 tidb 来说核心是 tikv,尤其是分布式架构和算法都是 rust 语言进行实现,很直接的说明一个问题,rust 性能和 cpp 非常接近,这些是 golang 无法满足的,足以说明 golang 性能是非常明显的劣势,所以你们不应该把这个案例提出来打脸。
NoneObject
NoneObject
兄弟,注意你很久了,起码一年多,发现你只要是有golang的新闻就会进来拉踩,搞的跟饭圈的人一样,知道你主推D语言也搞rust,但是真没必要捧rust的时候去猛踩golang,所以今天真想对你说几句,不同语言都有自己的优劣势,同样不同的人对不同编程语言的接受度和亲切度也不一样(这个亲切度主要是每个人的语言使用习惯,思维方式,语法顺眼度,标准库是否和心意决定的)。也许某个语言对你来时是蜜糖,但对别人来说是砒霜。编程语言只要使用者能发挥出其语言优势,编写出高质量的软件就好,没必要学饭圈的那套拉踩规则。每个人都会用自己的脚投票,选择适合自己的语言。请不要把饭圈的那套东西也带到编程的圈子,没意义。还有,你能不能成熟点?你这种心态怎么做开发,你这种心态也推广不了D语言和rust
久永
久永
人家只是基于比较优势,可能只是按照自己的判断更多的注意到大众不注意的go劣势,所以如鲠在喉,不吐不快罢了。并没有如果你说的主观的为捧而贬。相反,你倒是主观的臆断别人的主观目的,反倒正是表明了你才是你说的那种行为吧?
NoneObject
NoneObject
我观察他一年多了,各种golang的新闻都有他,我这条评论不是说的他这个新闻的这几条评论,他写了一些D语言的框架,对D语言做了一些贡献,同时也搞一点rust,但是对golang过于苛刻,为了推D语言经常猛踩golang不是一次两次。没啥想说的,饭圈的拉踩不可取。每门语言对于不同的人,理解不同,看到的优劣势也不同。很多时候没必要像他这样,每门语言能不能成气候,主要还是看大众的接受度,语言背后支撑者的实力,还有所开发的拳头软件,以及构造的生态,要说语言劣势,JavaScript这么劣的语言经过几十年发展后一样发展到了今天,虽然依然不够优雅,但是还是统治了前端。我想说的是针对别的编程语言的拉踩不可取,好好发展贡献自己喜欢的编程语言就好。
久永
久永
嗯!以观后效。
冰力
冰力
哪个朋友说的 docker 和 tidb?来我们聊聊细节,首先说这两个都是很成功的产品,尤其是 tidb 是我们国内团队刘总带头搞的。首先我们说一下 docker,基本上是使用了 golang 替代了 Python 去完成了一个作为方向的工作,只是体现了 golang 够简单,我承认简单是优势,但仅此而已。
冰力
冰力
minho,七牛云我们也在用,许总推广 golang 纯粹是为了宣传七牛云,我觉得比较成功,虽然大家都知道当时 golang 稳定性都是问题,但是我不知道这和 golang 哪些优势绑定了?制定了什么样的标准?开源了什么框架和架构?引领了什么方向?
x
xshrim
这个try把错误给踹到哪去了呢, 最终不还得判断么. 别的语言的catch还不是要catch多种exception类型. 除非偷懒全用一个catch捕获, 但显然这是不好的习惯, try catch非常诱导人偷懒. 反而go想直接避免这个问题, 哪出错哪处理. go语言整体就很暴露, 能露的尽量露给你看.
暮城暮雪
Go的一个核心理念-
让一切都是显示的。能肉眼可见。
独孤影
独孤影
干得漂亮,try个卵
oreak
oreak
净搞这些妖蛾子, try catch 不好吗
爽歪歪ES
defer不就行了吗?需要try吗?
一位极其不愿意透漏姓名的马先生
一位极其不愿意透漏姓名的马先生
挺好的,并不需要,可以全局捕捉,在加try,多此一举
返回顶部
顶部