纯吐槽帖 关于 go 的 err 和重载

[partystart]

写了几个月的业务了 写 err 真的吐了 牵扯到序列 /反序列话、有任何文件、io 操作的地方都会有 error

报的那么多 error 有啥用？ 报那么多 error 没能解决问题 第一行成功 下面的几处 error 第一行的 error 岂不是白打了？ 这种与业务无强关联的地方 与业务嵌套这么深 直接全局异常捕捉不就行了？

还有都 21 世纪了 居然不支持重载 输出一样 输入参数不一样 不能重载 就很无语。我写个方法功能一样 还得另外起个名字

这群设计者是学术界呆太久了？

[6IbA2bj5ip3tK49j]

<del>大道至简</del>🐶

[Mexion]

确实

[Wenco]

不支持重载的语言多了去了，换份 java 工作不好吗

[qq8331199]

不服就别用，别又当又立

[useben]

这群设计者是学术界呆太久了？
看到这句话就证明你连 go 的背景都没了解清楚....

[Mohanson]

新手骂很正常的.

对于第一点, go 是有你认为的全局异常捕捉的, 叫做 panic. 一部分语言不区分异常和错误, 一部分语言会区分, 如果你之前没有写过区分异常和错误的语言, 那么切换到 go 会非常不适应. 这点我在最初学习 Go 的时候也骂过, 因为我之前写的较多的是 Java 和 Python. 如果你是从 C 转, 那这种设计就会认为是理所当然的.

至于重载, CPP 社区观点就是分裂的, 后来的新语言大多数都认为是个坏设计(rust 和 go 举例), 因为其会带来"二义性". **所以问题不是“为什么 Rust 和 Go 不支持函数重载”，而是为什么要允许 Rust 和 Go 支持函数重载？只有在有正当理由的情况下，才能添加一个功能**. 但我们知道, 这两门语言在没有这个功能的情况下工作的很好, 创造了许多伟大的程序. (比如大多数 Go 反对者: 为什么 A 语言有这个设计而 Go 没有, 这就不是一个正当理由

当语言设计者做出决定的时候, 一定是正反两方都经过了激烈的较量, 并且其中一方获得了胜利(例如你认为很恶心的 Go 错误处理, 不支持重载等功能). 作为一个学习者, 你应该去了解当时正反两方的观点, 为什么反方会失败, 为什么正方会胜利, 而不是单纯的发泄.

[achenme]

代码行数等于工作量证明 狗头~

[cmdOptionKana]

这两点都是风格问题，你可以不喜欢，这是“偏好”，但你要是讲道理，却很难说这是“错误”。

比如重载，绝大多数情况下重载只是更 implicit 而已，没啥特别好处。

[Kasumi20]

这种系统语言一般都不支持重载，因为要做动态库之类的

[partystart]

@Mohanson 所以那些吐槽 python 空格符号的人

肯定是没有思考过为什么这么设计

就是单纯的发泄

[Leviathann]

学术界？ Go 几乎忽略了所有现代 PL 研究成果

[Mohanson]

这里贴一句我很喜欢的话:

```
在你说出 "我同意", "我不同意", 或 "我暂缓评论" 之前, 你一定要能肯定地说: "我了解了."

同意对方说法, 与不同意对方说法都一样要花心力来作判断的. 同意或不同意都有可能对, 也有可能不对. 毫无理解便同意只是愚蠢, 还不清楚便不同意也是无礼.
```


无论是赞同一个设计, 还是反对一个设计, 你一定要能肯定地说: 我了解这个设计背后的取舍. 然后才有资格发表自己的看法.

[cmdOptionKana]

@partystart 吐槽语言特性，绝大多数都是没搞清楚“偏好”与“错误”。

语言特性的设计，最最主要考虑的因素叫做 trade off, 如果吐槽一个特性只单方面说优点或缺点，那要么就是完全不懂 trade off (约等于完全不懂设计)，要么就是懂了但故意装傻带节奏。

[cmdOptionKana]

@Leviathann Go 不允许重载以及不允许传统的继承（而是选择了 delegation, composition 之类的代码复用机制），正是现代 PL 研究成果，而且 goroutine 直接引领风骚，几乎可以说创造了新的成果，其他语言纷纷效仿。

[partystart]

我都已经帮你们想好了怎么圆场了

为什么这么设计呢
回答一律都是大道至简

那为什么在 1.18 里面添加范型呢？
请问是不是又是大道至简？

能别跪舔吗？
好就是好 不好就是不好
哪来的那么多权衡利弊 少给自己加戏了行吗？


python 反人类缩进符
c++冗余到创始人都不敢说自己掌握了
java 啰里八嗦的继承划分
php 函数命名混乱

是不是也要吹出一个 123 来？

只要是人设计的都会有败笔
直接承认不行吗？
java 吹能承认 java 啰嗦
go 吹能承认设计的垃圾吗？

[jorneyr]

Go 很有意思的:
* 标准库的错误不带 stack ，后来受不了了，在 pkg 的仓库里搞了个带 stack 的 errors
* 开始说泛型怎么怎么样，最后 1.8 开始支持泛型了
* ...
* 很多大家希望，但是 Go 不支持的特性，Go 官方也写了不少文章解释为什么要这么干的合理性，但是慢慢的又把这些特性给加上了
* 网上有不少文章讨论 Go 推翻自己最初自以为傲的特性

[partystart]

@jorneyr 问就是大道至简
再问就是诺贝尔获奖者设计 要相信诺贝尔科学家
不行还可以吹谷歌嘛
你这么垃圾能比得上诺贝尔获奖者吗？

诺贝尔科学家发明切小脑治病 海洛因治病
也没见这群 nt 出来说

[mainjzb]

error 需要向 rust 学习
重载问题不大可以接受

[cmdOptionKana]

@partystart 别人没说你是无脑黑，你就率先说别人“跪舔”、“go 吹”，这种泼妇骂街式的说话方式不好吧？

而且你的逻辑也不是一般的混乱，你说：

“好就是好 不好就是不好，哪来的那么多权衡利弊”

你说说，不权衡利弊就能判断好不好？

判断好不好的唯一方法，不就是权衡利弊吗？难道靠占卜吗？

[darksword21]

你去找个 java 的工作不就得了…

[ch2]

c 里就是这样的，go 只是传承了 c 的解决方法

[kiripeng]

golang 没有全局覆盖的找 error ，不过这个有个好处，立即处理 golang 的错误，按理说不应该执行下来有错误，然后就是比较恶心的事 panic 不知道在哪，不过可以用 pkg.error %w 得到报错位置和 xx ，或者用 runtime.caller 使用，实在受不了就换个语言

[CosimoZi]

continuation 多少年前就有的东西, goroutine 包装下变成"引领风骚"的成果了. 最喜欢看 v 站不学无术 go 小将表演了.

[kiripeng]

@kiripeng 至于范型，现在的方案是 code generation 罢了，牺牲编译时间换取性能

[partystart]

@cmdOptionKana

什么叫好 什么叫做不好 谁掌握好的定义？

go 设计团队自己掌握 他们觉得好就是好

至于什么权衡利弊就更搞笑了 是个人就有个偏好 是个团队都有组织特性

go 设计团队要是喜欢用脚敲代码 他们也可以给 go 加这个特性

你回答下为什么之前不支持范型 下一次要支持范型

是不是也是权衡利弊？第一做的决定正确 第二次做的决定肯定也是正确？

go 团队不停的正确？

[yulon]

天天吹 Java 序列化格式化，然后写个 log 都能有漏洞是吧

[kett]

用 Go 写业务确实是麻烦，特别是如果你使用过 java 这种有着成熟生态的语言。

[Buges]

>这群设计者是学术界呆太久了？
恰恰相反，go 常常被批做“民科设计的语言”，因其重复很多古老语言的错误和缺乏现代成熟 pl 理论支持的特性。

[sagaxu]

less is more = design less coding more

[masterclock]

> 这群设计者是学术界呆太久了？
Go 放弃过去几十年语言界的研究成果，自己再搞一套，典型的 “现在的 XX 太臃肿了，我要做一个小而美的 YY”，最后成为更臃肿更屎山的 ZZ 。

Go1.18 加入了泛型，但是不支持泛型方法，导致无法写出高阶抽象来，还是残废。

[hutoer]

好像哪里看到一句话：golang 做简单的东西很简单，做复杂的东西很复杂

[secondwtq]

其实 Go 确实有自己的成果啊。Go 的整个历史可以看成一个巨大的技术实验，难道不算是成果么？

[EminemW]

我挺受不了 没有方法重载，同一个方法要写几次

[cmdOptionKana]

@partystart

你问："什么叫好 什么叫做不好 谁掌握好的定义？"

但这个问题问你才对吧，是你一直在说好不好的问题，我和那个 Mohanson 都在说偏好和取舍。

我第一条评论就说了：你可以不喜欢，这是“偏好”。

这已经说得很清楚了啊，每个人都可以有自己的偏好，我也没强求你要说 Go 好啊，能理解吗？

你又问：“你回答下为什么之前不支持范型 下一次要支持范型”

Go 官方一直没有说不做泛型，几年前官方的 Blog 就发文说清楚了，只是没选定方案而已，后续会增加。


@CosimoZi 概念的发明与推广是两回事，在 Go 之前 coroutine 并未引起业界的高度关注，Go 做出了一个非常优秀的实现，所以我说 “几乎可以说” 是成果。

[28Sv0ngQfIE7Yloe]

@yulon #26

啊这

[starcraft]

你喷 go 我毫无意见，愉快旁观。
但你要把 go 和学术扯上点关系，就不行了。上面人也提了，这货和学术界没半毛关系，建议喷到深处，甩点锅过去也可以。

[rekulas]

佛性点看待，go 的 err 确实有点不那么令人舒服
不过看过了 python 和 shell 的语法，又觉得 go 还是挺可爱的

[az467]

但凡那三个人正眼看学术界一眼，都不会做出 if err != nil 这种东西。

[Kininaru]

我赞同 #6 的说法，Golang 的 err 处理方法和 C 语言真的很像。C 语言里，返回异常（而不是诸如内存泄漏，数组越界的错误）时，就是返回 int 类型的，只不过 Golang 返回了 error 类型

[buffzty]

又是一个没学过 c 的菜鸟 喷 go 的 err.

[ffire]

“只要是人设计的都会有败笔
直接承认不行吗？”
好大的口气，只是你确定你看出来败笔了。你通篇都是从你个人感受出发来评价一个语言，没看到你有任何正面的，从理论逻辑上讨论说为啥那样不好，或那样更好。不用 Go 的都看不下去了。还是该有个类似 stackexchange 那边“顶踩”的机制，不然这种泼妇骂街似的吐槽语言的贴子都能冒头。还扯到学术界去了，真是无知不嫌丢人啊。

[hallDrawnel]

每一步处理 error 我觉得很好，尤其是业务逻辑，这样强迫那个人每一步都去检查并作出合理的判断，虽然麻烦，但是后期维护和回溯都很爽。

[james122333]

你可以都用异常处理 go 的异常处理是比 java 好的 不用整天在函数上 throws 还要因应更动 其它不多说了

[FightPig]

go 现在有泛型了，看看以后的各种骚写法吧

[janxin]

err 是个大问题，不过倒不是你说的场景。你需要的处理方式可以用 panic/recover ，反正业务无关不需要关心哪里崩得，只要能回去返回错误即可。

重载不是大问题，只要做好设计重载可以不需要。当然，前提得有泛型。

[cassyfar]

喷 go 的 err 真的很 low

java 规范的处理错误还得不停 rethrow 呢，错误包裹错误，更麻烦。

[lxml]

go 泛型这个，唯一能黑的就是 go team 磨磨唧唧，怎么就以讹传讹说 go 反对泛型了。

人家压根没说不搞泛型，只是无法在编译速度、运行速度、简洁性、向下兼容上取得平衡，go 官方都搞出多少套设计了，一直在自我推翻而已。

[partystart]

@hallDrawnel

数据库的各种问题 你应用层调 sql API 报一大堆 error 有卵用

写一大堆 error 你糊弄鬼呢？

@cassyfar


你是写几行 java 代码就出 exception ？ nil exception? index out ?

菜成这样 还是去卖菜吧

[cassyfar]

@partystart

lol 原来你写的都是些遍历数组的代码 笑死

[noparking188]

@Kininaru #39 #39 没用过 Golang ，不过感觉这种设计思想和 UNIX/Linux 很像哈，每执行完一次命令都会有状态码返回，标识是否正确执行

[MengiNo]

喷语言的其实完全可以去写半年 js 和 css 要求兼容 ie 678910 ，就老实了。

[agagega]

https://onevcat.com/2017/10/swift-error-category/
建议看一下 Swift 是怎么理解错误这个概念然后在语言里用不同的方式实现的

[hellodudu86]

建议上 boss 搜一下哪个语言工资高选哪个，光喷是没用的

[nicebird]

可以吐槽，但是也能理解，设计者不是学术界呆久了，而是非常实践。

工程上就是要把不确定消除，重载就是一种不确定性，写的和实际调用的要有一个脑补过程。错误处理是继承 C ，google 非常习惯这种方式，也是 google 工程实践。

[golangLover]

@nicebird 。。。google 的工程师哪里习惯这种方式。。。

[msaionyc]

@cassyfar 这也能有优越感吗

[Kininaru]

@noparking188 #50 是的，确实很像！

Unix 系的返回状态码，和 throw 系的 try catch 体系，我觉得各有各的好处，都挺不错的。

代码风格上我更喜欢 Unix 系状态码，写出来的代码比较好看。每次写 Java ，try catch 都是一小坨，还得缩进，看起来总感觉好别扭。

[pmispig]

你应该没用 C 写过东西吧，这个 err 和 c 的判断小于 0 差不多

[tairan2006]

err 设计是不行，但是重载并不是什么问题…

另外 go 显然不是太学术，而是太工程

[iyaozhen]

go 的 error 是比较烂，但“直接全局异常捕捉不就行了”像 java 那样一个 try catch 到底的（写法）我觉得更烂

“牵扯到序列 /反序列话、有任何文件、io 操作的地方都会有 error” 这个难道不是所有语言都这样？只是别的语言你可以不处理，但怎么说呢，你业务走不下去呀，真的线上出问题哪一步错了都不知道。

[interim]

@yulon 开发得有讲逻辑把？库漏洞跟 Java 有什么关系？想搞个漏洞哪个语言不可以？

[keepeye]

go 应该看作 c 的进化版，不是另一个 java 或 c++

[james122333]

@iyaozhen
只能说就算 java 你用全局错误处理 再到达前还是得不停的 throws 只能说 java 这方面超差 至于一直 try catch 在十分不好的公司很好用 符合他们细分的思维又要有 log 顺带可以降低效能

[lysS]

没学过其他语言，大学时只搞过 C ，现在 Go 与我很兼容。。。

[xxxcat]

发现大部分喷 Go 的几乎都一个模版，没一点新意

[Rasphino]

PL 学术界表示这锅我不背（

[WispZhan]

别人怎么说我先不管。
目前很同意 go 不适合写业务的说法，而且我也一直在说这个观点。

[james122333]

@WispZhan
如果以生态现有方案来讲是这样
但如果自己都会造轮子这些问题不存在
开发一样可以飞速
偏重业务的每个都差不多这种想法
只能唱"我们不一样"

[hallDrawnel]

@partystart 奇了怪了出错不处理你糊弄谁呢？

[Sparkli]

LZ 戾气好重...参考 https://www.v2ex.com/t/804676#reply52

[superfatboy]

@Sparkli 不光楼主，来 v2 的戾气都挺重

[partystart]

@hallDrawnel

sql 和第三方中间件出现问题 你业务怎么处理？


不停打 error 来糊弄鬼？
一个 API 包含几个 sql 请求 打一堆 error 有卵用

[partystart]

@iyaozhen

哦 我都忘了 go 之前是没有异常栈

引入了 pkg/errors 才找得到调用栈

也难怪 go 出问题不停打 error 出问题了了哪一行都找不到

21 世纪了以前连异常栈都没有 牛逼

[micean]

@james122333

因为 java 开发者所有的接口设计都是返回期望的类型，而不包含错误类型。
假如在调用的第 N 层方法里有一个 IO error ，不抛异常就没办法让业务逻辑走下去。
至于 @iyaozhen 说的“真的线上出问题哪一步错了都不知道”，难道 golang 没有异常栈？

[noparking188]

@Kininaru #57 #57 我也喜欢 UNIX 这种设计，应该是为了方便支持管道，若是抛出异常就没法将命令拼接成管道了，也没法衔接兼容不同程序。
想起大学时候学 C 看的《 C 程序设计语言》，建议每次 main 函数执行完 return 0 ，应该也是遵循 UNIX 风格

[hallDrawnel]

@cmdOptionKana 楼主来主要是表达情绪，而不是讨论问题。懒得讨论下去了。本身这个话题也是够无聊的。

[Hanggi]

Go 语言设计有一大特点，就是不仅把所有觉得没必要的功能都剔除了，还把不适合的人也剔除了。

明显楼主就是那个被剔除的人，虽心有不甘，但不适合就是不适合。
到这里骂骂咧咧发了一通牢骚并不能说服任何人，最后从 Go 语言阵营退出也算是造福社区。


人在挑选编程语言，其实编程语言也在挑人。

[aababc]

@partystart 是为了性能，感觉 go 对表的对象是 C/C++ 结果抢了 Python PHP 的市场份额，也是挺搞的！

[voidmnwzp]

@Hanggi go 小将经典言论 设计缺陷就是缺陷 还不让说了？

[partystart]

@Hanggi 那肯定不如 go 小将 毕竟都是天选之人嘛

全球语言排行 20 位 在谷歌 没一定牛逼都不能用 go 去开发项目

国内能用 go 那肯定是牛逼又牛逼 留下的肯定都是精英工程师


@micean 哪来的异常栈？敢不用 pkg/errors 这个包？

[james122333]

@micean
抛异常是种选择 但一串函式通通要抛是太过 uncaughtexception 照样抓的到 为何要写一堆无用代码
能觉得好开发纯粹是网络资源多外加 ide 助攻
go 现在的异常处理封装一下爽太多了
if err 照样封装一样爽

[james122333]

异常栈也蛮多余的 通常都是要准确知道哪步有问题
而非整串过程 过程自己知道也会追 单步侦错更会列出过程

[micean]

@james122333

事实就是封装就是爽，java 里所有异常均继承自 throwable 这一个类型，还可以自定义异常，开发者可以在 spring 里指定处理 throwable 以及其他异常，保证 request 可以顺利 response ，完全没有无用代码。
java 异常栈有多余的部分，但多余不是一个问题，完全可以准确的了解问题所在

[james122333]

@micean
有用的封装是爽 无用会很不爽 我说的是 throws 语句问题 还不能够不用
那只是错误类型 go 一样可以

[james122333]

你不爽 errors 包自己定义都可以

[james122333]

至于异常栈你确定 ide 不给你高亮你能一眼看出哪里有问题吗

[micean]

@james122333

有包名啊，哪里难了
而且 IDE 不仅能高亮，点一下还能直接调转到问题行代码，这么好用干嘛不用

[james122333]

@micean
我说的是不想写 throws 你跟我扯有类型
所以没错是 ide 辅助 然而辅助这个很多于的东西

[james122333]

是每个函数上面那个 throws

[james122333]

ide 辅助才好用 vs 原本就好用
给我选选后者

[h280254082]

总结 但凡和我的想法不一样的设计都是辣鸡设计 我就要喷 谁说有合理性就喷谁 在这贴里面认真去讨论某个设计对不对的可能需要多看些帖子就知道和某些人正经讨论是浪费时间了

[Glauben]

这种随随便便 XX 小将扣帽子的能是正经人？觉得 Go 好就是 Go 小将，Java 小将你好

[micean]

@james122333

为什么要写 throws ？ lombok 注解一下就可以了

[james122333]

@micean
依赖 lib 而且觉得写註解没有比较好
代码看起来就是要清爽

[flynaj]

这种就是语言特性，不可能完美，总要做出一些取舍。

[Austaras]

重载倒不是什么坏设计，单纯就是没什么用。。。

[techstay]

我也不喜欢错误码，trycatch 多好，谁要负责谁就去捕获异常，然后该咋写咋写就好了

[hpeng]

喷挺好的，希望像 go 范型一样，喷久就给你弄一个出来就更好了。

[hutoer]

重载还是有用的，比如：
Color::Color(0,0,255)
Color::Color("#FFFFFF")
Color::Color(Color::RED)

[cmdOptionKana]

@hutoer 关于重载看过一些讨论，比如你举的例子，改成

Color::ColorRGB(0,0,255)
Color::ColorHex("#FFFFFF")
Color::ColorName(Color::RED)

只是一种更显性的风格，很难说好不好，只能说各人喜欢的风格不一样。