水木社区手机版
- 主题:异常这玩意儿当初是哪个脑残发明出来的？
- 水木可真疯狂，这也censor
【 在 speedboy2998 的大作中提到: 】
: 污染性太强了。。。
: 老老实实地判断返回值不好好的吗？
--
FROM 221.218.161.* - 逐级的效率并不一定比直达天听效率高
而且很多人爱滥用try{}catch(...){}这种阻止直达天听的招式，对人围追堵截
【 在 speedboy2998 的大作中提到: 】
: 逐级，一级对一级负责。
:
--
修改:z16166 FROM 221.218.161.*
FROM 221.218.161.* - 感觉是：
能在哪一级解决，就在哪一级解决
适合在哪一级解决，就在哪一级解决
所以需要顶层设计：有哪些异常，在什么层级解决。
顶层也无法解决的，让它崩好了。一般人造的都不是原子弹。
【 在 speedboy2998 的大作中提到: 】
: 你 try catch 一般也是逐级吧， 总不能像下面这样：
: [code=c]
: int main()
: ...................
--
FROM 221.218.161.* - 异常现在都是查表的，哪一层有catch宣称自己能解决，那这层在表里就会有注册handler。
到处滥用catch(...)，就是万恶之源之一
【 在 speedboy2998 的大作中提到: 】
: 你 try catch 一般也是逐级吧， 总不能像下面这样：
: [code=c]
: int main()
: ...................
--
FROM 221.218.161.* - 你说的污染性，从另一个角度说正好就是顶层设计啊，
也就是事先规划好各个模块怎么抛异常、怎么处理异常，那样还怕什么污染呢，兵来将挡水来土掩。
而且也不是污染了，因为所有模块和人都知道会来点啥。
返回值就是适合局部
人类直觉通常是局部的，也符合没有人做全局设计时，单个码农自己搞定局部模块、函数的场景，但不一定是全局最优的
【 在 speedboy2998 的大作中提到: 】
: 问题是这玩意儿有污染性啊。如果能够内部消化不污染到外面来，我觉得没问题。
: 异常太有悖于人类正常思维模式。
: 用返回值判断，更天然地符合人类直觉。
: ...................
--
FROM 221.218.161.* - 这有啥问题？
你调用第三方库，要么捕获异常，要么处理返回码，不是一样的？
又不需要在调用第三方库的每个层级上都捕获它的异常（如果真这么做的话，算是误用 + 滥用，哈哈），也就是通常在第一层就做了隔离。
还有种情况是，你的代码到处直接调用抛异常的库，而不是对其封装一下，哈哈
【 在 speedboy2998 的大作中提到: 】
: 我说的污染性是：
: 我不想使用异常，但是用到的第三方库使用了异常，，我就不得不在调用他接口的时候瞿捕获异常。、
:
--
修改:z16166 FROM 221.218.161.*
FROM 221.218.161.* - 你可以换个库，或者自己撸一个库，这样就不用觉得自己被污染了、受委屈了
【 在 speedboy2998 的大作中提到: 】
: 导致我不得不用异常，污染了我。
:
--
FROM 221.218.161.* - 这不可能，那可能做的就是改变自己的观念，做到不再觉得用异常就是自己被污染了，哈哈
用返回码何尝不是一种被“污染”，各种库定义各种返回码
【 在 speedboy2998 的大作中提到: 】
: 这咋可能
:
--
FROM 221.218.161.* - 高频使用，不等于高频抛异常啊
如果某个地方可能会高频抛异常（比如被人不停攻击，输入非法的数字给std::stoi抛异常），你得加前置检查或者改变实现
【 在 overcomeunic 的大作中提到: 】
: 嗯，是这理
: 那咱们就回到标准库
: std::stoi <-- 这个会抛异常，咱们就讨论下这个抛异常是否合理
: ...................
--
FROM 221.218.161.* - 肯定要区分外部输入、内部输入
外部输入不可信，要做防御性编程，tainted data checking。
内部其他模块的输入不用这么严格，而且大部分情况下不应该是非法格式的数据
【 在 overcomeunic 的大作中提到: 】
: 数据处理的时候，你哪知道上游给你的是啥垃圾
: 正常的处理不应该是 ： 如果给的输入能正常处理，那就是正常值；如果处理不了，我给个默认值
:
--
FROM 221.218.161.*