@goool

返回一个 promise 列表并不是 send_x_target 的初衷：找出有哪些地址发不过去了。

我再具体一点来说吧，这个地址发不过去，从 connect 到 send 完成，是有几种可能的情况的：

1. 构造 socket 出错，例如因为 打开文件数太多之类的
2. connect 出错，可能是 Connection Refused 或 Timed out
3. send 出错，可能是等待回复超时，也可能是连接中断

然而，这里只有情况 2 里面的 Connection Refused ，才属于 “这个地址发不过去” （因为 Timed out 可能只是本机或者远程机器响应不过来）

3 这种情况，可能需要一点复杂的重试策略来完成任务
如果遇到 1 ， 根本不在设计的范围内， send_x_target 也不知道该怎么办

我不知道 golang 要怎么弄才够简洁，如果是 C#，我会这样来表达：

https://segmentfault.com/n/1330000004411185

@goool 关注点并不是返回 err 或者 try catch 的出发点是什么，先别忙着讨论气质。

让一个 stream socket 发送若干字节算不算 stream socket 能力之外的事情？不算吧？ stream socket 尝试发送之后发现 tcp 连接已经因为超时断掉了，再算不算 *正常* 设计内应该考虑的事情？ 算的吧？

好的，既然 stream socket 发送字节和要处理超时连接中断这种事情，都负荷你说的，可以使用 err 的场合。那么现在，我要通过 send_x_target(x, targets) 并发地启动 x 个 stream socket 发送到 targets 列表所指定的目标地址，然后找出有哪些地址发不过去了。

请问你要怎么设计 send_x_target 的返回值？

如果你说，这种场合不适合用返回值：请问要怎么解决这类多个 IO 复合的问题？

没想明白这类问题的抽象形式，我觉得是没有资格来讨论 try catch / err 是怎么设计的吧。

@codeaqua 哈哈，如有误伤，实属无奈，记得下次正确评估对手，毕竟跟疯子或者喷子开战，肯定是掉身价的，哈~ 走好不送。

我相信多数人都知道 coroutine 是什么鬼。
但是从 形式上 或者 实践上，怎么把 coroutine 和 处理大量 IO 的问题结合起来，不知道的人肯定更多——不然也不会有那么多人就在瞎吹 golang 了。

@codeaqua 为了帮你们科普，我这么热情主动，你们还说我偏执狂。你们自己说说到底谁才值得被 BS ？

https://en.wikipedia.org/wiki/Coroutine

“ According to Donald Knuth, the term coroutine was coined by Melvin Conway in 1958, after he applied it to construction of an assembly program.[1] The first published explanation of the coroutine appeared later, in 1963.[2] ”

看到没有， 1963 年就有这 coroutine 这种概念了。再看看下面的 coroutine 支持的语言列表？有没有什么感觉？

go 语言所解决的问题，只不过就是把 io 相关的 API ，跟 coroutine 和线程池 结合在一起，做成了一个语言。然后，再顺便按照发明人自己的特殊癖好，把 exception 砍一下，加了个 gc 。只要你喜欢，随便哪个语言封装一下库都可以做好这种功能。

我能理解你们为什么这么兴奋——因为以前你们用别的语言不知道怎么解决这类问题，现在有了，感觉自己的能力好像强了很多——是的， golang 降低了一点这些门槛，然而 golang 没有解决而你们也没有遇见过的问题依然存在。

@codeaqua

对排斥的东西当然是一黑到底了，人之常情。只不过令你等不高兴了，那你来啊，我从来不介意你们说我黑子，喷子，无理取闹——反正我又不掉一根猫。

对待排斥的东西，有的人斯文一点就呵呵，心里暗笑你个傻逼；像我这样粗鄙一点的就开喷，然后增加点谈资——心胸狭隘的人自然会抵制会反对，有眼光的人可能会看到别的不同的观点或者没接触过的领域；然后我继续很爽；我没觉得这有什么不好。

就算你说我偏执狂，也不会动摇我说的事情本身具有的合理性——如果恰好我说的是对的，那么我对我说的偏执不是有另外一种叫法叫做“对真理的追求”？呵呵。

我排斥 go 语言就是因为它是编程语言的倒退，当然我不排除它在某些领域确实很使用；这也算就算了，但是叫嚣什么“解决了异步模型侵入性问题”—— 这个本来就是一个 setjump longjmp 问题的扩展而已——我就觉得你们这帮 go 语言粉真是无知者无畏啊……是不是你们只听说过 goroutine 没听说过 coroutine 啊？

@codeaqua 如果返回错误并不具有不可替代性和优越性，那么按照简单的逻辑，抛出异常的做法就是具有不可替代型和优越性——这是我的观点。逻辑上是这么说当然是不够的，但是我也在此前的回复中说明了，什么情况下，抛出异常是比返回错误更合理更符合实践的做法。

你举的那个例子叫做 checked exception 的语法——声明了这种异常就一定要 catch ，这个只是脑残 Java 的特例， C# C++ 的 exception 都不会要求声明阶段指定 exception ；所以才会导致程序员不得不用偷懒的办法——是的，这就是偷懒，你说的这种情况——声明抛出任意异常——依然是程序员偷懒而不是异常机制有什么问题，只要程序员想“偷懒”，返回一个 err 一样可以绕过——更重要的是，返回一个 err 更容易导致 callsite 出现疏漏的问题，情形也是我此前所说的，在一个方法调用中可能出现不定多种 err ，，处理对应 err 的缺失会导致 panic 出现在预期以外的位置，更难调查。

--

golang 无非就是有 channel 这种东西吧，这也能够叫做非引入地解决异步模型问题？那什么语言不能呢？这本来就只是一个编程语言的库就可以解决的问题而已。

别卖弄你的术语，侵入式 intrusive 写过 C++ 的人都知道是什么意思，倒是你把 intrusive  这个词用在同步异步模型，倒是创举了。

如果你是想说“异步代码的传染性”，譬如 C# 里面的 async 关键字会传染得到处都是，而 golang 没有这个问题。 那你真是太小看 C# 了。

golang 在这个问题上唯一的优势就是，语言规定死了这样解决异步问题，不需要发明其他的框架——然而在我看来，这样的语言也就适合代码流水线上的工人去用了。跟 Java 没什么两样。

@codeaqua 如果你觉得你写任何代码都有操作系统的代码质量，加上足量的测试，那当然用什么语言健壮性都会很好。所以，我的说法是在软件工程经验来说，使用异常机制健壮性*更*容*易* 提高，可重用性更好。

我不觉得你举操作系统的例子能说明错误返具有不可替代性甚至优越性，事实上，很多操作系统也是内部实现了异常抛出机制的，只是在开源的里面很少这样做而已。

你认为错误返回和异常机制的优劣只是场景问题。那我们来说说吧，在 go 语言常用的场景，你认为什么情况下，用错误返回优与用异常 ？

@bombless C++ 不推荐用异常主要是因为没有 GC 。

返回错误，和抛出异常，根本就是不一样的结构；既不是顺序也不是分支，而是跳转，而返回错误依然是一个顺序结构之中。

异常确保不会继续向下执行，无需异常所在的上下文来保证。返回错误得自己完成这件事情。

结构的差异大概有点像 python 的 yield 和 return 。

@BurNFans

你也确实没有人身攻击，我只是认为你说的东西 not helpful 。
祝你在以后的道路上少浪费生命。

@BurNFans

你觉得你很清楚，那你倒是说嘛。
不过看你的发言风格，打一耙就走，你倒是有真小人之风。

@codeaqua

“没有结果”只是你的信念。
实际上，软件工程的经验就是 exception 的代码结构比 返回 err 可重用性和健壮性高得多。

@BurNFans

按照 golang 的设计方式，要调用不定多个可能产生 err 的函数的例子，这不是很常见嘛。

见你这么谦虚承认自己见识少，那我就给你举个例子吧，典型的 map_reduce 类型工作。

假设你要写一个爬虫，现在有一个要爬的 url 任务列表，你要根据这个列表去获取对应的内容并且进行分析，并且分析的时候也是调用别处的代码来分析的，分析结果也跟网络一样是有可能出错的。

那么，不管你串行也好并行也好，你总是得循环地执行这个

result, err = crawl_and_analyze(url)

现在由于这个任务列表是外部读入的，动态的

你来告诉我，你打算怎么在循环体里根据 err 找出哪里处问题了？

@BurNFans

假设你当我是白痴…… 估计你也不会跟白痴说话吧？不分析

假设你没有当我白痴，那么一个按照预期返回了结果的函数会 crash 吗？
你认为我会连这么基本的问题都没弄清楚的话…………嗯嗯，我和你之间必定出了一个自大狂。

为什么是可能导致？这就是我想批评 golang 的问题所在了。

回到那个讨论场景， do_transaction 会调用不定多个其他函数（例如在循环体中调用），这些函数都是可以返回 err 的。

现在其中执行到某一步的时候，某个函数返回 err 了， 那 do_transaction 中要怎么判断是否终止事务？获得这个 err 之后要怎么执行回滚？

仔细想象这个问题，你就会发现，当你调用的代码并不是直接通过源码明文调用（就是说代码中直接通过函数名调用），而是间接地调用的时候， err 的信息就是模糊的，被隐藏在调用接口之下的。那这个时候 err 信息实际上是没用的。

--

问题是如何进一步扩散变得严重的呢？ 现在我的某个间接调用返回了一个 err ， 那么一般来说是不是意味着这个函数没有返回程序上下文期望可以继续执行下去的返回结果？

就是说 ret, err = do_sth() 总是 要么 err 为 nil 要么 ret 为 nil ，这也是 golang 为什么能歪打正着使用这种设计的前提 convention 。

但是因为 我在 do_transaction 中并不真的 清楚 调用的函数是 do_sth1 还是 do_sth2 ，那么我的 这个 err 是不是只能靠手工穷举所有的可能性？但是又因为 do_transaction 中你所间接调用到的子过程实际上是动态的，所以所有你现在源代码中的静态穷举显然是徒劳的。

那么，总是会有没被检查到的 err 或者 ret 会扩散到后续的代码去，你总不能在所有的地方都准备好 panic 和 recover 吧？

那你现在明白为什么会不定期 crash 了没？

@BurNFans

为了表达我可以收你为徒弟的诚意，我说的而且可能导致你理解有偏差的话在这里
“你还要手工去分析 err 的各种可能性，否则漏了一个的话，你就会惊喜的看到上线后不定期 crash ”

你喷吧。

@BurNFans

你从哪里得到“我认为 golang 里面有 err 会直接导致 crash ” 这种印象？
你连我说了什么都没弄清楚，这种水平？还是先跟我学学怎么做喷子好不好？

@yougg 嘿嘿，你说我双重标准。

那要不我发个参考标准出来，你看看有没有道理，看看谁比较像人身攻击？

https://www.zhihu.com/question/20519813

@yougg

如果说骂人两句说他蠢会把人骂死的话…… 那活该啊！哈哈哈哈

弱者躲在理想的道德世界里沾沾自喜，也就只能喷一下敢出头的人来寻找无聊的优越感了。

话说，虽说我的用词很有攻击性，但要说我是人身攻击，我是不会承认的，因为我既没有评判讨论者的道德水平，也没有故意偏离讨论的话题来试图夺取话语权。

然后，继续你的道德审判吧——你这种反而比较像人身攻击，知道不？

顺带科普一个

http://stackoverflow.com/questions/10052464/difference-between-dynamic-loading-and-dynamic-linking

@CRRV

上来就乱喷的是你吧，好歹我也装作有技术含量地写了几千字和一个 case 。
不过，作为一个同在喷的人，我不介意你什么时候喷。

不过喷的姿势麻烦端正一点好不好？逼格显得太 low 我会不屑与你同喷的。

说一堆辩证法下正确的话有什么意义吗？什么东西不是有人喜欢有人不喜欢？
是不是只有喜欢的人才能喷，不喜欢的请闭嘴？如果这是你家，我同意你的立场。
但是，作为一个（伪）学院派，任何反理性的做法，我是肯定要喷的。
不用 go 语言就不能批评 go 吗？ go 培养脑残我就是要喷。

其实我是知道 go 的编译器能生成 SO ， 1.5 正式支持嘛，但无奈有人声称单文件最好，那我只好降维攻击了。

说正题，你说 go 的编译器能支持动态链接，能生成 动态链接库，是对的。

但这并不等于说， go 语言自身 *已*经* 支持 *动态加载* Dynamic Link vs Dynamic Load 。

譬如说 C ， C 语言是通过系统 API 来完成动态库加载的，动态库更新了， free 掉再 load ，就可以执行新的动态库的功能。

又譬如 C# Java C++ ，当然也是支持的，在同一个进程的声明周期内反反复复加载不同的动态库。


好了，轮到你了，你说 Go 支持动态加载吗？—— 除非你说自己写个解释器吧……