编码习惯之异常处理
@(常识)
对于 系统或者是其他的大型IT系统，最怕的事情
- 第一是系统出现了异常我不知道，等问题闹大了用户投诉了才知道出问题了。
- 第二就是出了问题之后无法找到出错原因。
针对这2个问题，说说我对异常是怎么样想的和规定异常处理的。
第一个问题，系统出异常了我不知道，等技术支持问的时候才知道。
这个问题出现非常多，而且非常严重。经常会出现用户反馈、投诉过来说某个功能不可用，技术支持找的时候开发人员再定位分析之后，才发现之前的某一步出错了。随着 业务流程越来越复杂，和周边子模块一堆集成，一堆的后台队列任务，任何一块都可能出问题。
举几个例子：
技术支持：呀，透传云又传不了数据了？NB模块下发命令又发不下去了？设备怎么添加失败啊？
开发人员：好，我查一查。
开发人员A：哎哎哎，世超你看看看 API 是不是获取数据有问题啊，志远NB服务器是不是停了啊。。。。。
针对某些业务，在流程上当然可以采取相对的策略来保证，但从开发的角度来说，任何规定都无法保证一定不会发生错误，老虎也有打盹的时候，我只相信代码。
代码方面：
- 没事不要乱
try catch尤其是 API 异常都抛出来怎么了 一个e.getMessage包装到data数据区再加个错误码怎么了？ 直接抛到最上层用统一的全局异常处理去处理，里面做机制比如说：邮件或微信推送到开发组长和开发人员那里。（尤其是后台队列之类的操作） - 新手最容易犯的错误，到处捕获异常，到处加空判断，自以为写出了“健壮”的代码，实际上完全相反。导致的问题，第一代码可读性很差，你如果工作了看到一半代码是
try-catch和空判断你会同意我的观点的，第二更加重要的掩盖了很多错误，日志是不会有人看的，我们的目的是尽早让错误抛出来。