Transferred from the public account [Program Ape DD]
Introduction:
For large-scale IT systems, the most feared thing is that the system is abnormal. I don't know. When the problem becomes a big problem, the user complains that there is a problem. The second is that the cause of the error cannot be found after a problem occurs. In response to these two problems, let's talk about how our project team stipulates exception handling.
Once again, I declare my point of view. In this series of posts, there are no technical points. They are just some programming experience, and it is based on the project background that most of the code is simple CRUD, and the flow of developers is generally high. Down. I hope the reader's focus will no longer focus on technical points. Most of the work does not require any technology, as long as you write the code well, it is enough for you to face it easily!
Closer to home, back to the first question, I don't know if the system is abnormal, and I won't know until the problem gets bigger and users complain. This problem occurs many times and is very serious. I don't know if other companies have such a scenario. For our company, there are often user feedback and complaints that a certain function is not available. After the developer locates and analyzes, it is discovered that a previous step was wrong. The company's business process is very complex, with a lot of integration with surrounding systems, and a lot of background queue tasks, any of which may go wrong.
Here are a few real cases from this year:
1 A certain system failed to successfully cancel the account, and the last location found that the ldap password was modified and not updated some time ago
A certain process failed, and finally it was found that a NAS disk was newly added to the integrated system, and the firewall was blocked and could not be accessed, resulting in an error.
3. A certain function cannot be used. Check the log and find that the background scheduled task has been stopped for several days.
For these functions, of course, relative strategies can be adopted in the process to ensure that, but from the perspective of development, no regulations can guarantee that errors will not occur. When tigers doze off, I only believe in code.
Post a very common code, do you think there is any problem with this code?
In my opinion, this code is very problematic many times !
Exceptions are thrown away. Even if the exception prints the stack, no one will see it! Unless the user tells you something is wrong, you don't go to the logs! So, looking at the code that seems to be very rigorous, it actually doesn't work much
异常处理再加上框框2处的空判断，天衣无缝的避开了所有正确答案。本来需要更新文档，结果什么错误没有报，什么也没有做。你后台就算打了日志堆栈又怎么样？
所以，我对开发人员的要求就是，绝大部分场景，不允许捕获异常，不要乱加空判断。只有明显不需要关心的异常，如关闭资源的时候的io异常，可以捕获然后什么都不干，其他时候，不允许捕获异常，都抛出去，到controller处理。空判断大部分时候不需要，你如果写了空判断，你就必须测试为空和不为空二种场景，要么就不要写空判断。
强调，有些空判断是要的，如：参数是用户输入的情况下。但是，大部分场景是不需要的（我们的IT系统里面，一半以上不需要），如参数是其它系统传过来，或者其他地方获取的传过来的，99.99%都不会为空，你判断来干嘛？就抛一个空指针到前台怎么啦？何况基本上不会出现。
新手最容易犯的错误，到处捕获异常，到处加空判断，自以为写出了“健壮”的代码，实际上完全相反。导致的问题，第一代码可读性很差，你如果工作了看到一半代码是try-catch和空判断你会同意我的观点的，第二更加重要的掩盖了很多错误，如上面图片的例子！日志是不会有人看的，我们的目的是尽早让错误抛出来，还有，你加了空判断，那你测试过为空的场景吗？
web请求上的异常，不允许开发人员捕获，直接抛到前台，会有controller处理！见我的编码习惯 - Controller规范
所以上面的代码，我来写的话是这样的，清晰明了。
另外一种后台定时任务队列的异常，其实思路是一样的，有个统一的地方处理异常，里面的代码同样不准捕获异常！然后异常的时候邮件通知到我和开发人员，开发组长必须知道后台的任何异常，不要等用户投诉了才知道系统出问题了。
另外，开发组长需要自己定义好系统里面的异常，其实能定义的没有几种，太细了很难落地，来，异常不要继承Exception，而是继承RuntimeException，否则到时候从头改到尾就为了加个异常声明你就觉得很无聊。
总结：
开发组长定义好异常，异常继承RuntimeException。
不允许开发人员捕获异常。（异常上对开发人员就这点要求！异常都抛出到controller上用AOP处理）
后台（如队列等）异常一定要有通知机制，要第一时间知道异常。
少加空判断，加了空判断就要测试为空的场景！
这篇文章，我估计一定有很多争议，这些规则都和常见的认识相反，我在公司里面推广和写贴分享的时候也有人反对。但是，你要知道你遇到的是什么问题，要解决的是什么问题？我遇到是很多异常本来很简单，但由于一堆健壮的try-catch和空判断，导致问题发现很晚，可能很小一个问题最后变成了一个大事件，在一些IT系统里面，尤其常见。大家不要理解为不能加空判断，大家见仁见智吧。反正我是这样写代码的，我发现效果很好，我很少花时间在调试代码和改bug上，更加不会出现前台返回成功，后台有异常什么也没有做的场景。
最后对新手说一句，不要养成到处try-catch和加空判断的恶习，你这样会掩盖掉很多错误，给人埋很多坑的！