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

[partystart]

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

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

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

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

[Buges]

@hutoer 上面没打完，constructor 没有提供额外的好处，限制了初始化函数的命名（这也是需要重载的一个主要原因），不能为不同的情况使用不同有意义的命名。至于命名有静态检查，并且一般都有特定的 convention,没什么混乱的。另外不要只从 OOP 的角度观察，简单的函数其实更好理解。

[hutoer]

@Buges 抛出异常和返回错误值还是不一样的，调用的地方处理也不一样。就算是返回错误值，可以 Result<Color,Error>，Error 是基类，你这样 Result<Color,ParseError>，有其他类型的错误咋返回？所以 Color::from_rgb(u8,u8,u8)和 Color::from_hex(String)返回类型没有区别。

我那个例子，参数个数不一样的。

[dobelee]

@hutoer 个人觉得这种写法非常糟糕。应传递颜色类型，或使用不同的方法名。

[Buges]

@hutoer return 和 throw 是不同的控制流，需要用不同的方式处理，但本质上都是返回数据给调用方，无论通过 return 还是 throw 。实际“返回”的数据类型是不一样的。
如果签名写了 ParseError ，自然是表明该函数只可能返回这一种错误类型，如果还可以返回其他类型那自然要写成所有可能类型的 super type ，这个和 checked exception 本质是一样的。
参数个数不一样可以用 vararg ，或者包装到一个 collection literal 里，或者写成 macro 。如果只需要几种特定数量的参数，可以分别写成 add2 、add3 等不同函数，比起导致的问题重载并不能提供足够的好处。

[agagega]

C++因为长期以来没有 optional 类型（而且即使有了也有额外 overhead ），所以构造函数只能用异常表示构造失败。

而不管是 C++风格的构造函数还是手写函数构造，都存在语义不明的问题。Swift 风格的具名参数和重载可以解决，并不一定需要带不同名字的函数。

但即使没有构造函数，这个创建对象的函数也还是需要某种方式来「创建」对象，这种 C 风格花括号的方式有是不如构造函数一样灵活。

另外在面向对象的继承关系里，构造函数就显得很自然，非构造函数虽然也可以做到类似效果，但就会很别扭。

[fregie]

@partystart 什么叫好，什么叫不好，这几年开发者们已经用脚投票了，你觉得什么叫好，什么叫不好？
本身都不是面向对象的语言，你非拿它来写业务，写完了还说不好用，那能说你什么？但凡明白点面向对象的也会明白 go 本身就不适合写业务，编程语言没有银弹，不同语言有各自擅长的领域。

[LoNeFong]

打起来 打起来 我就喜欢看 V 站语言战争, 一堆人瞎瘠薄操心!
赚几个钱啊?
房贷换完没啊?
真 tm 无聊

[ly020044]

我就喜欢看你们打字互喷，下次你们继续哈。

[nmap]

别用不就得了嘛，人家也没逼着你用，也没让你掏一分钱

[adoal]

你是不是对 PLT 的学术界有什么误解……

go 的错误处理硬生生把本该用 sum type 来做的事（ either ok result or error info ）做成了 product type （ a tuple with both ok result and error info ）……哪个学术界是这么玩的？