@pkupyx 我个人的建议仍然是优先选择正确性。如果真的可以把错误归类为 95%的不需要自己处理的错误，和 5%的需要自己处理的错误，你可以把前者和后者分开，前者一路返回，后者自己专门处理。

不是非常建议使用 panic 和 recover ，因为它们都是函数级别的跳转逻辑——如果你要在循环中处理错误，使用 panic 和 recover 很可能会导致遗漏。

另外，方便地处理错误往往会让程序员有精力正确地处理错误，但不是说方便地处理错误就会让程序员一定能正确地处理错误。另一方面，正确地处理错误在某种程度上可以让错误处理更方便，但跨过了某个分界点后，正确处理错误又不能与方便地处理错误相妥协。所以这必须是一个与实际业务紧密相关的问题，如果不相关，那么你的做法就会既不方便也不正确。

虽说我日常看不惯 go ，但我仍然要问：你为什么需要一个统一的错误处理逻辑？你真的想清楚了原因，而非一时偷懒选择了它？

你或许应该了解到，和错误处理相关的问题永远都包括两个议题：如何正确处理错误，和如何方便地处理错误。但很可惜绝大多数人都混淆了它们，并把它们视为同一个问题。

有必要，你可以写一个库和其他人的库比试一下，再不济也可以到处打广告吹嘘嘛

虽说师医公是很不错的选择，但我还是想提醒一下：
以后人口减少，老师不一定当得长久。
老年常见病的科室会吃香，儿科的科室萎缩。
公务员最风光最稳定，但是大家都想挤进去，财政又吃紧，想要一直吃香喝辣的人恐怕要失望了——当然即便如此也是比上不足比下有余。

这种自我“矮化”现象的原因，不是房间里的大象还是什么呢？看来外宾淆普及得不错。

[cppreference]( https://zh.cppreference.com/w/cpp/language/templates)

workflow 和 asio （无论是 boost 版本还是非 boost 版本）相比，或者与 libevent,libuv 相比，有何优势或者特殊之处？

在商业公司面前，开源作者就像 19 世纪的英国工人，自由出卖自己的劳动力，自由到一无所有。