- 主题:异常这玩意儿当初是哪个脑残发明出来的？
那是因为项目里没人提前规定好有哪些异常、各种异常在哪里处理，也就是没顶层设计
所以每个人只看到自己的局部，自然是一头雾水，哈哈
【 在 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.*
这个chatgpt回答你又准确又全面
【 在 chaobill 的大作中提到: 】
: 我现在还不明白为什么异常出现会 new 一个异常类。 错误和异常的区别在哪里，如何严格定义。 为什么一定是类呢，原始应该是什么东西吧
--
FROM 221.218.161.*
所以要measure。性能极为敏感的地方肯定不能抛异常了
【 在 ensonmj 的大作中提到: 】
: 只是一条物料的json解析异常， 完全可以丢弃的，但latency极具升高，导致整个请求可能都废了
--
FROM 221.218.161.*
其实异常最大的问题，可能是人员要从上到下都得跳出自己的舒适区（局部的返回码），哈哈
--
FROM 221.218.161.*
你说得有些道理
不过所有人都不舒适未必是事实，比如已经在用异常的那些人（但不是滥用）
还有种可能是有些问题也许就没有很简便的解决办法，类似Rust搞的那些用来解决c++没很好地解决的问题而引入的特性，c++码农刚接触这些特性时可能也会觉得处处受掣肘，很不爽，连个双向链表都搞不出来。越过这个阶段后会好很多。
而且不能把自己的惰性甩锅给某些特性，c++那些guru没强迫人用异常，而只是极力推荐用异常
【 在 yuanmo 的大作中提到: 】
: 工具是给人用的，一个设计要搞到所有人都不舒适，然后也拿不出一个大部分人觉得舒适的使用方法，足以说明这是一个失败的设计。
:
--
FROM 221.218.161.*
哪些是私货？
有些人连guru的书都没读过，对异常的看法完全凭自己的经验和猜测，这才是可怕的地方。
之前有人连异常的实现，都不舍得花时间反汇编看看（也可能看不懂汇编），就断言还是每个函数有prolog和epilog的大开销
【 在 hhoking2012 的大作中提到: 】
: 布道者太可怕，尤其夹带私货
--
修改:z16166 FROM 221.218.161.*
FROM 221.218.161.*
自己查资料，哈哈
【 在 hgoldfish 的大作中提到: 】
: 对了，我也没有看过。之前在本版有提到过, amd65 架构下使用下使用查表实现。那么应该是 throw 没有开销，catch 也没有开销，但 try 有开销吧？
: 另外, i386, arm32 和 arm65 架构下的开销不知道怎么样呢？
:
--
FROM 221.218.161.*