闯祸了,我用了一个‘<>’操作符引发的线上Bug

简介: 闯祸了,我用了一个‘<>’操作符引发的线上Bug

一、发现问题


昨天下午四点多的时候,一位同事找到我说,我所负责的系统中修改机器状态的功能不可用了。我当时是感到非常开心的,因为摸了这么多天的鱼,终于有活干了!

于是我在正式环境发了一个请求给出问题的接口,谷歌浏览器按F12,发现接口报错了,Http的返回码是500,很显然这是服务端报错。然后我查看报错的信息,发现:


20201111161403323.png

原来报错的原因是:


'<>' operator is not allowed for source level below 1.7


出错的代码是:


List<Server> serverList = new ArrayList<>;


很显然这是与JDK版本的问题有关。


二、解决问题


由于这行代码是我为了完成公司安全组的需求——记录所有写操作日志而写出来的,我是想把被修改了状态的Server的信息保存到一个List里面,然后将List记录到日志里。当时在本地写完并测试通过后,是没有问题的,所以才发版上线。毕竟我本地的编译环境是JDK1.8,所以显然没有问题。但是到了线上,由于项目太老,其JDK低于1.7,就不支持在JSP页面里面使用’<>'了。


由于我担心修改了线上的JDK版本导致其他一些版本不兼容的Bug出现,就干脆把这行代码删掉了,换成了StringBuffer类去做Server的信息记录。测试通过后再发版上线,就把Bug解决了,日志记录也是正常且美观。


三、启发


这个Bug虽然没有造成重大损失,但它给了我一些启发。在维护一个老项目的时候要考虑到老项目使用技术的版本与当前主流技术版本的兼容问题,对于Java开发者而言,特别是要弄清老项目的JDK版本,这对于以后写出少Bug的代码事半功倍。


相关文章
|
5天前
|
程序员 测试技术
程序员的“Bug之旅”:为何无法一次性写出完美代码?
程序员在软件开发过程中难以一次性写出完美代码,需要不断修改和调试,即“改Bug”,这是由多个因素共同作用的结果。技术层面的复杂性、管理和流程上的不足以及个人能力和认知的局限性都是导致这一现象的重要原因。然而,这并不意味着无法避免或改进。通过加强需求管理、建立有效的版本控制和测试机制、推动团队知识共享以及鼓励代码审查和自我反思等措施,可以降低改Bug的频率和成本,提高软件开发的效率和质量。辩证地看待这一问题,既要理解其存在的合理性,也要积极寻求改进之道,以实现更好的产品和服务。
14 2
|
Oracle Java 关系型数据库
使用了这个神器,让我的代码bug少了一半(下)
使用了这个神器,让我的代码bug少了一半(下)
使用了这个神器,让我的代码bug少了一半(下)
|
5天前
|
消息中间件 前端开发 关系型数据库
🤔️测试问我:为啥阅读量计数这么简单的功能你都能写出bug?
🤔️测试问我:为啥阅读量计数这么简单的功能你都能写出bug?
|
6月前
|
数据库 C++
《C++避坑神器·十七》找到程序崩溃Bug的一个实用方法:dump调试
《C++避坑神器·十七》找到程序崩溃Bug的一个实用方法:dump调试
76 0
|
12月前
|
程序员 C语言
爱心代码--C语言特供(可直接复制,亲测有效)
爱心代码--C语言特供(可直接复制,亲测有效)
14970 0
|
Python
上古代码漫游记(二):把陷阱去掉了,反倒踩进了新的陷阱?
上古代码漫游记(二):把陷阱去掉了,反倒踩进了新的陷阱?
82 0
|
Java 中间件 程序员
最网最全bug定位套路,遇见bug再也不慌了
最网最全bug定位套路,遇见bug再也不慌了
242 0
|
Java 应用服务中间件 Docker
同事嫌我改Bug慢,原来是没掌握这些代码Debug技巧
代码Debug调试是研发工程师日常工作中必不可少的重要组成部分。进行代码Debug调试的目的无非就两个,一个是自我检查代码逻辑是否有问题,便于自己将Bug消灭在测试介入之前;另一个是进行线上问题排查定位,找到实际在跑业务的过程中出现的Bug。
同事嫌我改Bug慢,原来是没掌握这些代码Debug技巧
|
前端开发 计算机视觉 Python
代码报错还好说,源码报错才难搞!分享自己源码报错的解决过程!
代码报错还好说,源码报错才难搞!分享自己源码报错的解决过程!
93 0
代码报错还好说,源码报错才难搞!分享自己源码报错的解决过程!
|
测试技术
软件测试面试题:软件上线后有bug怎么处理?
软件测试面试题:软件上线后有bug怎么处理?
169 0