- 主题:异常这玩意儿当初是哪个脑残发明出来的？
我怎么感觉心智负担降低了？
因为阅读代码的时候，只要关注主业务流程，而不是需要去关注出错了怎么办。
【 在 ensonmj 的大作中提到: 】
: 异常是通过栈回溯一层层检查，非常耗时，肯定比返回值判断满。唯一的好处就是写代码的人不用每一层写这个check，但给读代码的人带来了极大的心智负担，因为你很难找到这个异常有没有处理，哪儿处理的，就是个巨大的飞线。如果飞线多了那就成面条了。
--
FROM 120.37.21.*
那是因为项目里没人提前规定好有哪些异常、各种异常在哪里处理，也就是没顶层设计
所以每个人只看到自己的局部，自然是一头雾水，哈哈
【 在 ensonmj 的大作中提到: 】
: 异常是通过栈回溯一层层检查，非常耗时，肯定比返回值判断满。唯一的好处就是写代码的人不用每一层写这个check，但给读代码的人带来了极大的心智负担，因为你很难找到这个异常有没有处理，哪儿处理的，就是个巨大的飞线。如果飞线多了那就成面条了。
--
FROM 221.218.161.*
不光心智负担降低，也不需要那么多分支预测了，ziqin上面也说了
【 在 hgoldfish 的大作中提到: 】
: 我怎么感觉心智负担降低了？
: 因为阅读代码的时候，只要关注主业务流程，而不是需要去关注出错了怎么办。
:
--
FROM 221.218.161.*
那是你的权力和自由
【 在 foliver 的大作中提到: 】
: 我在公司项目里面明确禁止使用任何异常。如果要引入第三方库，带有异常的也禁止引入。
--
FROM 221.218.161.*
B.S喷过，编译器的开发者在call chain等的优化上花了很多时间，效果显著，但是花在exception优化上的时间相比而言很少
他也强调过多次，慢不慢，是需要measure后再说话的，而不是武断地认为就一定慢
【 在 ensonmj 的大作中提到: 】
: 异常是通过栈回溯一层层检查，非常耗时，肯定比返回值判断满。唯一的好处就是写代码的人不用每一层写这个check，但给读代码的人带来了极大的心智负担，因为你很难找到这个异常有没有处理，哪儿处理的，就是个巨大的飞线。如果飞线多了那就成面条了。
--
FROM 221.218.161.*
不，我就碰到过有人拿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.*
相比 assert 我更喜欢反向抛异常
LoginException::ThrowOn($flag,"登录错误。。#1");
少一层缩进，多爽
【 在 ziqin 的大作中提到: 】
: 我用exception的准则是：
: 1. 函数运行时出错率<1%，也就是说错误是一个真正的小概率异常，而不是业务状态 and
: 2. caller没有因对错误的逻辑
: ...................
--
FROM 223.198.82.*