肯定要区分外部输入、内部输入

外部输入不可信，要做防御性编程，tainted data checking。

内部其他模块的输入不用这么严格，而且大部分情况下不应该是非法格式的数据

【 在 overcomeunic 的大作中提到: 】
: 数据处理的时候，你哪知道上游给你的是啥垃圾
: 正常的处理不应该是 ： 如果给的输入能正常处理，那就是正常值；如果处理不了，我给个默认值
:
--
FROM 221.218.161.*

是这样，不然两下就溢出越界了，被人利用远程执行。

【 在 z16166 的大作中提到: 】
: 肯定要区分外部输入、内部输入
: 外部输入不可信，要做防御性编程，tainted data checking。
: 内部其他模块的输入不用这么严格，而且大部分情况下不应该是非法格式的数据
: ...................
--
FROM 113.246.194.*

业务场景不一样，很多错误不是调用api的直接caller可以处理的，反馈链太长代码没法处理。

一个很简单的例子就是：

买东西确认支付的时候，突然api报网络断开的错误。这个错误可能涉及到重连，重初始化等等一系列操作，但是调用支付的caller不可能在这么高的业务层面上。这个时候，抛异常，高层面catch，做一系列清理工作是最合适的


【 在 ensonmj 的大作中提到: 】
: 我的观念是处理不了的错误直接dump，能恢复的错误返回值。  
--
FROM 122.234.62.*

你不一定能穷尽所有异常

不同类型异常，处理方式处理时机完全不一样，有的要处理，有的不要，有的要终止，有的要记录，有的要带病运行，要做到全方位比 try catch 更好只怕也不容易

【 在 speedboy2998 的大作中提到: 】
: 污染性太强了。。。
: 老老实实地判断返回值不好好的吗？
--
FROM 222.70.133.*

异常是通过栈回溯一层层检查，非常耗时，肯定比返回值判断满。唯一的好处就是写代码的人不用每一层写这个check，但给读代码的人带来了极大的心智负担，因为你很难找到这个异常有没有处理，哪儿处理的，就是个巨大的飞线。如果飞线多了那就成面条了。  
  
【 在 ziqin (子青|会挽雕弓如满月|西北望|射天狼) 的大作中提到: 】
:  业务场景不一样，很多错误不是调用api的直接caller可以处理的，反馈链太长代码没法处理。
:  
:  一个很简单的例子就是：
:  
--
FROM 116.232.116.*