对付大型IT系统，最怕的工作第一是系统呈现了异常我不知道，等问题闹大了用户投诉了才知道出问题了。第二就是出了问题之后无法找到堕落原因。针对这2个问题，说说我们项目组是怎么样划定异常处理惩罚的。

再次声明我的概念，我这系列贴内里，没有什么技能点，都是一些编程的履历之谈，并且是成立在项目配景是大部门代码都是简朴的CRUD、开拓人员活动大程度一般的环境下。但愿读者的重点不要再存眷技能点。大部门事情中不需要什么技能，你只要把代码写好，足够你轻松面临！

言归正传，说回第一个问题，系统出异常了我不知道，等问题闹大了用户投诉了才知道。这个问题呈现很是多，并且很是严重。我不知道其他公司有没有这种场景，对我们公司而言，常常会呈现用户反馈、投诉过来说某个成果不行用，开拓人员定位阐明之后，才发明之前的某一步堕落了。公司业务流程很是巨大，和周边系统一堆集成，一堆的靠山行列任务，任何一部都大概出问题。

举几个本年真实的案例：

1 某系统销户无法乐成，最后定位发明前段时间ldap暗码修改没有更新

2. 某个流程失败，最后发明集成的系统新增加了NAS盘，防火墙不通无法会见导致报错。

3、某个成果无法利用，查察日志发明靠山按时任务已经停了好几天。

针对这些成果，在流程上虽然可以采纳相对的计策来担保，但从开拓的角度来说，任何划定都无法担保必然不会产生错误，老虎也有瞌睡的时候，我只相信代码。

贴一段非经常见的代码，各人以为这段代码有没有问题？ 

在我看来，这段代码许多时候问题出格大！

1. 丢掉了异常。异常就算打印了仓库，也不会有人去看的！除非用户汇报你出问题了，你才会去找日志！所以，看着仿佛很严谨的代码，其实浸染并不大
2. 异常处理惩罚再加上框框2处的空判定，天衣无缝的避开了所有正确谜底。原来需要更新文档，功效什么错误没有报，什么也没有做。你靠山就算打了日志仓库又怎么样？

所以，我对开拓人员的要求就是，绝大部门场景，不答允捕捉异常，不要乱加空判定。只有明明不需要体贴的异常，软件开发，如封锁资源的时候的io异常，可以捕捉然后什么都不干，其他时候，不答允捕捉异常，都抛出去，到controller处理惩罚。空判定大部门时候不需要，你假如写了空判定，你就必需测试为空和不为空二种场景，要么就不要写空判定。

强调，有些空判定是要的，如：参数是用户输入的环境下。可是，大部门场景是不需要的（我们的IT系统内里，一半以上不需要），如参数是其它系统传过来，可能其他处所获取的传过来的，99.99%都不会为空，你判定来干嘛？就抛一个空指针到前台怎么啦？况且根基上不会呈现。

新手最容易犯的错误，处处捕捉异常，处处加空判定，自觉得写出了“结实”的代码，实际上完全相反。导致的问题，第一代码可读性很差，你假如事情了看到一半代码是try-catch和空判定你会同意我的概念的，第二越发重要的掩盖了许多错误，如上面图片的例子！日志是不会有人看的，我们的目标是尽早让错误抛出来，尚有，劳务派遣管理系统，你加了空判定，那你测试过为空的场景吗？

web请求上的异常，不答允开拓人员捕捉，直接抛到前台，会有controller处理惩罚！见我的编码习惯 – Controller类型

所以上面的代码，我来写的话是这样的，清晰明白。

别的一种靠山按时任务行列的异常，其实思路是一样的，有个统一的处所处理惩罚异常，内里的代码同样禁绝捕捉异常！然后异常的时候邮件通知到我和开拓人员，开拓组长必需知道靠山的任何异常，不要等用户投诉了才知道系统出问题了。

别的，劳务派遣管理系统，开拓组长需要本身界说好系统内里的异常，其实能界说的没有几种，太细了很难落地，来，异常不要担任Exception，而是担任RuntimeException，不然到时候从新改到尾就为了加个异常声明你就以为很无聊。

总结：

1. 开拓组长界说好异常，异常担任RuntimeException。
2. 不答允开拓人员捕捉异常。（异常上对开拓人员就这点要求！异常都抛出到controller上用AOP处理惩罚）
3. 靠山（如行列等）异常必然要有通知机制，要第一时间知道异常。
4. 少加空判定，加了空判定就要测试为空的场景！