程序员你为什么这么累【续】:编码习惯之异常处理

导读:

对于大型IT系统,最怕的事情第一是系统出现了异常我不知道,等问题闹大了用户投诉了才知道出问题了。第二就是出了问题之后无法找到出错原因。针对这2个问题,说说我们项目组是怎么样规定异常处理的。

再次声明我的观点,我这系列贴里面,没有什么技术点,都是一些编程的经验之谈,而且是建立在项目背景是大部分代码都是简单的CRUD、开发人员流动大水平一般的情况下。希望读者的重点不要再关注技术点。大部分工作中不需要什么技术,你只要把代码写好,足够你轻松面对!

言归正传,说回第一个问题,系统出异常了我不知道,等问题闹大了用户投诉了才知道。这个问题出现非常多,而且非常严重。我不知道其他公司有没有这种场景,对我们公司而言,经常会出现用户反馈、投诉过来说某个功能不可用,开发人员定位分析之后,才发现之前的某一步出错了。公司业务流程非常复杂,和周边系统一堆集成,一堆的后台队列任务,任何一部都可能出问题。

举几个今年真实的案例:

1 某系统销户无法成功,最后定位发现前段时间ldap密码修改没有更新

  1. 某个流程失败,最后发现集成的系统新增加了NAS盘,防火墙不通无法访问导致报错。

3、某个功能无法使用,查看日志发现后台定时任务已经停了好几天。

针对这些功能,在流程上当然可以采取相对的策略来保证,但从开发的角度来说,任何规定都无法保证一定不会发生错误,老虎也有打盹的时候,我只相信代码。

贴一段非常常见的代码,大家觉得这段代码有没有问题?

在我看来,这段代码很多时候问题特别大!

  1. 丢掉了异常。异常就算打印了堆栈,也不会有人去看的!除非用户告诉你出问题了,你才会去找日志!所以,看着好像很严谨的代码,其实作用并不大
  2. 异常处理再加上框框2处的空判断,天衣无缝的避开了所有正确答案。本来需要更新文档,结果什么错误没有报,什么也没有做。你后台就算打了日志堆栈又怎么样?

所以,我对开发人员的要求就是,绝大部分场景,不允许捕获异常,不要乱加空判断。只有明显不需要关心的异常,如关闭资源的时候的io异常,可以捕获然后什么都不干,其他时候,不允许捕获异常,都抛出去,到controller处理。空判断大部分时候不需要,你如果写了空判断,你就必须测试为空和不为空二种场景,要么就不要写空判断。

强调,有些空判断是要的,如:参数是用户输入的情况下。但是,大部分场景是不需要的(我们的IT系统里面,一半以上不需要),如参数是其它系统传过来,或者其他地方获取的传过来的,99.99%都不会为空,你判断来干嘛?就抛一个空指针到前台怎么啦?何况基本上不会出现。

新手最容易犯的错误,到处捕获异常,到处加空判断,自以为写出了“健壮”的代码,实际上完全相反。导致的问题,第一代码可读性很差,你如果工作了看到一半代码是try-catch和空判断你会同意我的观点的,第二更加重要的掩盖了很多错误,如上面图片的例子!日志是不会有人看的,我们的目的是尽早让错误抛出来,还有,你加了空判断,那你测试过为空的场景吗?

web请求上的异常,不允许开发人员捕获,直接抛到前台,会有controller处理!见我的编码习惯 - Controller规范

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

另外一种后台定时任务队列的异常,其实思路是一样的,有个统一的地方处理异常,里面的代码同样不准捕获异常!然后异常的时候邮件通知到我和开发人员,开发组长必须知道后台的任何异常,不要等用户投诉了才知道系统出问题了。

另外,开发组长需要自己定义好系统里面的异常,其实能定义的没有几种,太细了很难落地,来,异常不要继承Exception,而是继承RuntimeException,否则到时候从头改到尾就为了加个异常声明你就觉得很无聊。

总结:

  1. 开发组长定义好异常,异常继承RuntimeException。
  2. 不允许开发人员捕获异常。(异常上对开发人员就这点要求!异常都抛出到controller上用AOP处理)
  3. 后台(如队列等)异常一定要有通知机制,要第一时间知道异常。
  4. 少加空判断,加了空判断就要测试为空的场景!

这篇文章,我估计一定有很多争议,这些规则都和常见的认识相反,我在公司里面推广和写贴分享的时候也有人反对。但是,你要知道你遇到的是什么问题,要解决的是什么问题?我遇到是很多异常本来很简单,但由于一堆健壮的try-catch和空判断,导致问题发现很晚,可能很小一个问题最后变成了一个大事件,在一些IT系统里面,尤其常见。大家不要理解为不能加空判断,大家见仁见智吧。反正我是这样写代码的,我发现效果很好,我很少花时间在调试代码和改bug上,更加不会出现前台返回成功,后台有异常什么也没有做的场景。

最后对新手说一句,不要养成到处try-catch和加空判断的恶习,你这样会掩盖掉很多错误,给人埋很多坑的!

原文发布于微信公众号 - 程序猿DD(didispace)

原文发表时间:2017-09-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏小程序·云开发专栏

你不知道的Node.js性能优化

仅仅是简单的升级 Node.js 版本就可以轻松地获得性能提升,因为几乎任何新版本的 Node.js 都会比老版本性能更好,为什么?

8.3K5
来自专栏Kevin-ZhangCG

Java学习路线图分析

33510
来自专栏hbbliyong

设计模式学习--面向对象的5条设计原则之开放封闭原则--OCP

一、OCP简介(OCP--Open-Closed Principle): Software entities(classes,modules,functions...

2938
来自专栏微信公众号:Java团长

Java后端学习流程

首先,我个人比较推崇的学习方法是:先学java前端,也就是HTML,css,js,因为学习java以后肯定是往java ee方向发展的,学习完前端,在学习后端很...

2331
来自专栏web前端教室

前端组件“可编辑表格”,怎么设计才好呢?先得有思路

大家好,今天是0618,今天的先行者计划的主题是“可编辑表格”的第一次课。 既然是一个前端组件,那么就涉及到如何设计的问题。我们不是单纯的要实现一个可编辑表格...

2275
来自专栏樊华恒的专栏

海量之道系列文章之弱联网优化 (六)

基于一个快速和高效管理的链路之上,做好IO调度和控制,也是提升效能和改善用户体验的重要环节,本节主要来探讨 IO 管理与 强监控。

3350
来自专栏Java技术栈

Java 9、10、11,哪个才是 Java 程序员的本命?

之前,我们在《Java 10无跳票发布,主推的新特性引争议》的文章中做了一个小的调查,主要是调查现在的Java程序员都在使用哪个版本的Java?根据调查结果,绝...

2093
来自专栏牛客网

腾讯一面应用开发

最遗憾的,叫写冒泡排序都能写数组溢出,非科班面对算法题真的紧张。凉凉。 面试官是做php的,我用java。 问了http和https的区别。 答: 后者是前者的...

2966
来自专栏java一日一条

大量参数与信息丢失之间不可不说的故事

代码越少就越好?对象越少就越好?这些都是真的吗?由绝大多数情况来看,这还真的都不一定。

601
来自专栏Danny的专栏

学生信息管理系统验收总结

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/huyuyang6688/article/...

2393

扫码关注云+社区

领取腾讯云代金券