- 主题:异常这玩意儿当初是哪个脑残发明出来的？
领导让你办事，结果出了意外，你解决不了，你领导也解决不了，事情又比较急，你是逐级上报还是直接向大领导汇报？
【 在 speedboy2998 的大作中提到: 】
: 污染性太强了。。。
: 老老实实地判断返回值不好好的吗？
--
FROM 122.234.62.*
然后有个区域总和你说，大领导和我是单线联系，你爱咋样就咋样吧
【 在 speedboy2998 的大作中提到: 】
: 逐级，一级对一级负责。
:
--
FROM 122.234.62.*
异常的运用场景更像： 出了问题以后，直接领导没有处理预案的时候，在工作群里大喊，然后谁能解决谁来回复
--
FROM 122.234.62.*
你捕获了以后，可以转成自己内部的错误码啊
用错误码就要判断错误码，就会多出predict branch，对延时不敏感的无所谓，对延时敏感的，差别还是很大。
【 在 speedboy2998 的大作中提到: 】
: 导致我不得不用异常，污染了我。
:
--
FROM 122.234.62.*
我用exception的准则是：
1. 函数运行时出错率<1%，也就是说错误是一个真正的小概率异常，而不是业务状态 and
2. caller没有因对错误的逻辑
运行时出错误状态>1%，说明需要把错误状态当成一个业务状态来处理，那么调用者必须要有应对这个业务状态的逻辑，如果直接领导没有应对这个业务状态的逻辑，说明组织构架有问题
--
FROM 122.234.62.*
try catch肯定不会逐级，又不能解决问题，catch到又有什么意义
exception扔出去，谁都没解决方案，直接大领导catch到，要么“那就坏菜了，先停车吧”，要么“滚粗，继续运行”
【 在 speedboy2998 的大作中提到: 】
: 你 try catch 一般也是逐级吧， 总不能像下面这样：
: [code=c]
: int main()
: ...................
--
FROM 122.234.62.*
所以关键在判断，某一个状态到底是异常，还是正常业务状态，这个带有一定的主观性
单次异常处理开销肯定是大的，但是数量应该及其小
if else开销肯定小，但是顶不住数量大，而且会破坏代码结构
好的代码肯定两者都会用，只是程序员素质和公司业务管理构架的问题
【 在 overcomeunic 的大作中提到: 】
: 抛异常，处理异常
: 跟
: 处理返回码的 if else
: ...................
--
FROM 122.234.62.*
你不做数据清洗的么？
【 在 overcomeunic 的大作中提到: 】
: 数据处理的时候，你哪知道上游给你的是啥垃圾
: 正常的处理不应该是 ： 如果给的输入能正常处理，那就是正常值；如果处理不了，我给个默认值
:
--
FROM 122.234.62.*
业务场景不一样，很多错误不是调用api的直接caller可以处理的，反馈链太长代码没法处理。
一个很简单的例子就是：
买东西确认支付的时候，突然api报网络断开的错误。这个错误可能涉及到重连，重初始化等等一系列操作，但是调用支付的caller不可能在这么高的业务层面上。这个时候，抛异常，高层面catch，做一系列清理工作是最合适的
【 在 ensonmj 的大作中提到: 】
: 我的观念是处理不了的错误直接dump，能恢复的错误返回值。
--
FROM 122.234.62.*
如果你项目里很多超过21亿的数字，那你的确不应该用stoi这个函数
使用场景的问题，不要甩到函数身上
【 在 overcomeunic 的大作中提到: 】
: 数据清洗不也得看数据是不是合法的么？
: 如果清洗的时候又是用这个，该啥样子还是啥样子
: 比如超 21亿的数字
--
FROM 122.234.62.*