- 主题:异常这玩意儿当初是哪个脑残发明出来的？
我的观念是处理不了的错误直接dump，能恢复的错误返回值。
【 在 ziqin (子青|会挽雕弓如满月|西北望|射天狼) 的大作中提到: 】
: 我用exception的准则是：
: 1. 函数运行时出错率<1%，也就是说错误是一个真正的小概率异常，而不是业务状态 and
: 2. caller没有因对错误的逻辑
:
--
FROM 39.144.39.*
异常是通过栈回溯一层层检查，非常耗时，肯定比返回值判断满。唯一的好处就是写代码的人不用每一层写这个check，但给读代码的人带来了极大的心智负担，因为你很难找到这个异常有没有处理，哪儿处理的，就是个巨大的飞线。如果飞线多了那就成面条了。
【 在 ziqin (子青|会挽雕弓如满月|西北望|射天狼) 的大作中提到: 】
: 业务场景不一样，很多错误不是调用api的直接caller可以处理的，反馈链太长代码没法处理。
:
: 一个很简单的例子就是：
:
--
FROM 116.232.116.*
不，我就碰到过有人拿catch异常，然后修改状态去走另外一条路的代码。如果看代码不关心他怎么处理异常就根本搞不懂他在干嘛。
另外，pytorch里面也有这么干的
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 我怎么感觉心智负担降低了？
:
: 因为阅读代码的时候，只要关注主业务流程，而不是需要去关注出错了怎么办。
:
--
FROM 117.136.120.*
也许是吧，但我觉得除非code review非常严格，否则很难做到
【 在 z16166 (Netguy) 的大作中提到: 】
: 那是因为项目里没人提前规定好有哪些异常、各种异常在哪里处理，也就是没顶层设计
:
: 所以每个人只看到自己的局部，自然是一头雾水，哈哈
:
--
FROM 117.136.120.*
我碰到过异常导致latency急剧上升的情况，所以印象中异常比返回值慢一个数量级。当然最新的编译器还是不是这样我就不确定了。
【 在 z16166 (Netguy) 的大作中提到: 】
: B.S喷过，编译器的开发者在call chain等的优化上花了很多时间，效果显著，但是花在exception优化上的时间相比而言很少
:
: 他也强调过多次，慢不慢，是需要measure后再说话的，而不是武断地认为就一定慢
:
--
FROM 117.136.120.*
不过从机制上看异常需要分配内存，栈回溯，肯定快不了。
【 在 z16166 (Netguy) 的大作中提到: 】
: B.S喷过，编译器的开发者在call chain等的优化上花了很多时间，效果显著，但是花在exception优化上的时间相比而言很少
:
: 他也强调过多次，慢不慢，是需要measure后再说话的，而不是武断地认为就一定慢
:
--
FROM 117.136.120.*
只是一条物料的json解析异常， 完全可以丢弃的，但latency极具升高，导致整个请求可能都废了
【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 这不简单，都异常了，你还指望速度？
: 未知异常先开个IO记录下来嘛
: 【 在 ensonmj 的大作中提到: 】
: : 我碰到过异常导致latency急剧上升的情况，所以印象中异常比返回值慢一个数量级。当然最新的编译器还是不是这样我就不确定了。
--
FROM 116.232.21.*
问题是rapidjson内部要抛异常，除非换一个不用异常的json库…
【 在 z16166 (Netguy) 的大作中提到: 】
: 所以要measure。性能极为敏感的地方肯定不能抛异常了
:
: 【 在 ensonmj 的大作中提到: 】
: : 只是一条物料的json解析异常， 完全可以丢弃的，但latency极具升高，导致整个请求可能都废了
--
FROM 116.232.21.*
我不知道别人怎么样，我对自己经历的项目都是想尽量搞懂每一块代码的。
【 在 ziqin (子青|会挽雕弓如满月|西北望|射天狼) 的大作中提到: 】
: 这个也没有问题
:
: 底层关心底层的业务逻辑，高层关心高层的业务逻辑。超过底层权限的逻辑，在抛出异常时由高层做出指示，这是很符合逻辑的事，不光是代码，人力组织构架也应该是这样。
:
--
FROM 117.136.120.*