生产环境用的代码，每几行业务代码写出来都要用 try...catch...之类的包裹着吗？值检查等

[a251922581]

不然的话像 Python 和 NodeJS 语言万一用户输入类型错误，或者函数遇到未预期的类型，整个运行中的程序就挂了。
运维转开发，发现 Python 和 NodeJS 每写一两行代码就得写五六行的 try...catch 捕捉错误+输出错误信息包裹着业务代码。。随之而来的大小括号和缩进。。

[lihongjie0209]

取决于你的异常是不是真正的异常, 不要让异常作为你的条件判断或者是前置条件判断.
前置条件判断就是运行这个函数必须满足的条件, 比如你所说的类型错误, 这些条件应该在业务逻辑之前就检测并做出相应的应对措施, 而不是等待运行到业务代码的时候才退出, 这样的话你系统的状态就改变了, 你所谓的 try catch 也就没有什么作用了.

举个例子:

原版
用户输入: 正常参数 1, 异常参数 2
程序执行: 使用正常参数 1 执行删除操作
使用异常参数 2 执行添加操作
程序爆出异常, 你捕捉并打印
现在你系统的状态已经改变了, 用户参数是异常的, 但是用户却执行了删除操作.

改进 1:
用户输入: 正常参数 1, 异常参数 2
程序执行: 参数校验, 发现异常参数并提示用户

这样的话你就保证了系统的状态不会处于中间状态. 这叫做提早失败(我也忘记怎么翻译了)

改进 2:

用户输入: 正常参数 1, 异常参数 2
程序执行: 使用正常参数 1 执行删除操作
使用异常参数 2 执行添加操作
程序爆出异常, 你捕捉并在异常处理中执行回滚操作, 把删除操作回滚

这样也可以保证你系统的状态, 这叫做失败的原子性, 缺点也很明显, 你需要记录很多状态并手动执行事务管理, 而且有些状态是不可回滚的.

改进 3: 参考 java spring 中事务管理的实现, 我目前还没有看到这一块.

以上内容来自<effective java>.

[wy315700]

90%以上的代码其实都是为各种异常状况而写的。。。

[readercn]

先检查参数异常，各种 edge case，有问题就 return error 吧，最后处理业务代码。

[arnoldFu]

执行前进行参数校验

[cloverstd]

就算是弱类型语言，用户输入的你也要检查吧
不能全部让『前端』做校验

[Sapp]

如果不用考虑各种蛋疼情况，写业务该是多简单？因为你总想象不出来用户能玩出来什么花样，demo 和上线产品的区别之一就是应对各种复杂情况的处理吧？

[q397064399]

@Sapp 如果不用覆盖各种变态的边界条件 还要程序员干嘛

[jswh]

防御性编程，不要等到代码出错。

[loading]

if err != nil

你知道我上面这一个写了多少次？结果就是，我已经写到我键盘宏里面了。。。

[Livid]

https://sentry.io/

[Todd_Leo]

尝试在生产代码中把你的异常处理用 if...else...语句替换吧, 因为经过充分的测试后你需要对代码中哪里会出现什么异常非常清楚.

[atcdef]

用户输入必须检查其合法性，因为万一你的用户是一只狗坐在电脑前呢

[Arnie97]

@cloverstd 前端校验过的也要再校验吧，为了安全性考虑