查看原文
其他

许久以后,你会感谢自己写的异常处理代码

鱼鹰Osprey 鱼鹰谈单片机 2022-10-14

源:公众号【鱼鹰谈单片机】

作者:鱼鹰Osprey

ID   :emOsprey

很多时候,我们因为关注最终的结果,而总是忽略其它的情况。所以我们写的代码并不是那么的健壮。

这篇文章属于程序员内功修炼,值得一看。

写代码的时候,有几个阶段可以参考一下(鱼鹰经历并总结):

阶段只要最终的结果

处于这个阶段的一般都是初学者,眼里只有一个目标,那就是程序运行成功,从不考虑其他因素。

比如一个简单的 SPI 驱动程序,最终的目标只要一个,通信成功。所以当需要延时时就会采用死等方式等待结果,而不会考虑其他可能出现的结果,比如因为某种原因导致引脚电平被持续一个电平不变,导致死循环;比如因为你的延时,导致其他人功能无法及时处理。

这个时候的思考总是过于理想化,不是因为自己太理想,太乐观,而是因为没有足够的经历告诉你,这样写是有问题的。

因为没有经历过,所以初学者也就考虑不了那么多,所以你看初学者的代码会很简单,是一条直线,逻辑很清晰,没有岔路。

阶段二:做一些常见的异常处理

随着经历越多(不管是网上看到的还是自己经历的),渐渐地,自己的代码变得多了一些,功能还是那个功能,只是这时候的你考虑的更多,更全面,你渐渐的增加了各种异常处理。

比如你不再使用死等方式延时,而是增加了一个等待时间的超时处理;又比如你写的程序不再只有if里面的内容(条件为真),还有else(条件为假)。

这个时候的你眼里不再只有最终的结果,还有在运行过程中可能出现的其他情况,并且会对这些情况做处理。

阶段三怀疑一切

这个阶段的你不再相信任何东西了,即使它是那么的可靠。

你总是在函数开始处检查传入的参数(如果有的话),判断指针是否为空,判断数据是否在需要的范围内,等等。

总是在使用指针、数组的时候小心翼翼,深怕一不小心就越界了,而这种BUG只有经历的人才懂到底有多难查。

总是在异常的地方做出一些动作,如返回错误代号、如打印错误消息等。

不管怎样,在出现问题后,你总是能够快速的定位问题,而这,得益于你对异常的处理。

阶段做好善后工作

阶段三可能让你很快的定位问题,但是一旦出现问题,程序还是无法正常执行下去,比如申请的资源(内存、信号量等)没释放,又比如关闭的中断在异常后未重新打开等等。

所以异常处理代码除了能很快定位BUG外,还要做好善后处理,这样才能让程序健壮的一直运行下去。


鱼鹰曾在《代码写完了,你要花多少时间测试?》一文中介绍了一些调试方法,今天,继续更深入的探讨。

(uCOS II代码片段)

很多人其实不明白,为什么一定要在函数开头检查参数,这不是很浪费时间的吗(从上面可以看到,参数检查有时候比真正需要执行的代码还要多)?不说指针,就说一些普通变量,为什么要检查?检查的意义又在哪里?

浪费时间?

首先说说浪费时间的问题,确实,因为总是在开头检查参数,会浪费CPU的时间(鱼鹰一开始也非常不喜欢),但是当你经历了各种难查的BUG之后,你会发现,这点时间还是浪费的起。

而事实上,软件开发一般都会有两个版本,一个是Debug版本,一个是Release版本,只要通过宏进行控制,那么就可以在稳定之后,不再检查这些参数了。

但是有些重要的数据,即使稳定了,也不能放弃对它的检查,否则一旦出现问题,就是灾难。

所以在检查时,还要考虑这些检查是否在Release版本也是需要的,即按重要性分开检查。

为什么要检查?检查的意义又在哪里?

这些检查就像是函数的护城河,保证即使参数错误,也不会导致异常问题,比如数组越界,计算出错等。

那么我们要问了,参数怎么会错误,代码都是固定死的,有经验的都知道,参数是保存在或寄存器的,怎么会错呢?

你说内存数据保存时有问题?保存时为1,读出时为0?

别逗了,如果真是这样,那还怎么玩?程序根本没办法跑好吧(遇到强干扰可能会出现这种情况,甚至可能CPU执行流程都是乱的,最终只能重启,这个鱼鹰倒还没遇到过)。

我们可以认为存在RAM和FLASH的数据在存储和读取方面没有问题,那么又是什么导致了参数出错呢?

溢出

前面说过,参数有可能保存在栈里面,如果有些栈溢出了,参数被破坏也就可以理解了。(关于栈,可参考笔记《今天,你的栈溢出了吗?》)

数组越界、野指针等指针问题

一旦越界,那么产生的破坏力不可想象。

所谓越界,就是修改了不属于你的变量。比如一个数组,你操作了数组外的数据(不管是数组前面的还是数组后面的)。

而越界根据位置又可以分为三种情况。

第一种,stack,比如你在栈里面申请了一个数组,越界了,那么修改的就是栈内容。

第二种:Heap。你通过malloc申请的内存,如果操作失误,那么就会修改不属于你的空间。

第三种。全局变量(data。如果操作失误,也会出现问题。

其实,越界这种问题不一定就只会修改这些单独的区域,可能是两个区、三个区一起修改毕竟指针可不管修改的地址到底属于哪个区,还有一种是野指针导致的异常操作,那么它修改的位置只有鬼知道了(鬼好像不懂程序)。

比如你申请了一个数组,通过传入的参数修改数据,如果不限制参数大小,你确定它不会把你数组后所有的内存都给清零?!


如果硬要为上面三种情况划分处理难度等级,那么最容易也最快解决的就是全局变量的修改,为什么?因为地址比较固定,而ARM内核有神器处理这种情况,如果出现概率高的话,一查一个准,所以鱼鹰都不怎么苦恼这种问题。

最难解决的是堆的修改,这种问题比栈更难找。原因就在于,内存动态申请和释放,可能这次修改的是这个位置,没出现问题,下次修改另一个地址,就出现了问题,这种是最难查的。而栈的空间一般不会太大,而且他的存取都是有规律的,要稍微好查一些。


可能你会问,参数会保存在寄存器里面,那么寄存器的数据有可能被异常修改吗?

异常修改的可能性很小,因为对于C语言而言,寄存器是透明的,用户很难操作这个。

但是,虽然说参数传入之后被修改的可能性很小,但是传入前修改的可能性还是很大的,比如你传入的参数是一个全局变量,那么这个全局变量是可能被异常修改的啊!

所以,参数检查,是一个健壮程序必须要有的,这是防止产生重大问题最重要的护城河。而越早检查出问题,那么越容易定位问题

蝴蝶效应大家都知道,千里之堤毁于蚁穴大家也知道,用在程序里面也是很合适的。


可能你会说,我对自己有信心,我的技术杠杠的,绝对不会出问题。

真的是这样吗?

第一、时间久了自己都忘了。

工作时,常常完成了一个项目,下一个项目马上来了,如果老项目需要维护,不需要一两年,只要一两个月,如果你没有参数检查、异常处理的好习惯,一旦你修改了代码,那么很可能因为某些疏忽,导致难以发现的BUG,而解决这些BUG的时间,比你写这些异常处理代码更多。

但是在你刚开始写这份代码的时候,因为思路清晰,考虑的比较多,有哪些异常很清楚,那么很容易写出那些异常处理代码。

就比如鱼鹰去年写了一份通过位绑定地址,批量配置引脚的时钟、寄存器信息的代码,那么今年再复用代码的时候,因为自己的疏忽,很可能需要大量的时间解决BUG,那我写这份代码的意义就不存在了(写这份代码就是为了在标准库中通过端口和引脚号快速配置引脚),而如果说,一旦因为疏忽导致的问题,程序会自动帮你检查,那么解决问题就很快了。

第二、维护。

不管是别人维护,还是自己维护,当项目需要更改需求时,如果因为某些疏忽,导致了BUG,那么解决起来费时费力,而且即使你这次解决了,难道下次还要重蹈覆辙吗?

第三、合作开发

一个项目可能不是一个人完成的,而是多人合作。而每个人的水平有高有低,你敢说别人不会写出有问题的代码?你敢说自己一定不会写出有问题的代码?

而且即使别人没有写出BUG,但因为某些原因,需要修改或屏蔽你的代码,如果你的代码能自动提醒出这些异常,那么定位问题也就不难了。

而鱼鹰为什么写代码的时间会比测试长,除了掌握大量的调试技巧外,就是因为在写的时候,会考虑很多,并且这些考虑,大部分会以代码的形式存在,少量的会以注释或者#warning、#error 形式存在,而其中,最好的方式是代码形式,因为它能保证程序正常运行,即使不能正常运行,也应该打印消息以提醒用户问题在何处。

所以,鱼鹰总是很庆幸自己当初花了不少时间去写异常处理代码,而这些代码,如果需要事后弥补的话,相信花的时间会更多(定位问题、回想当初自己如何思考、补充异常处理代码,这些都要时间)。



推荐阅读:

终极串口接收方式,极致效率

为什么说你一定要掌握 KEIL 调试方法?

延时功能进化论(合集)

指针,很难吗?| 解析指针的过程与意义(一)

如何写一个健壮且高效的串口接收程序?

KIEL 调试那些事儿之窗口展示——变量(二)

打了多年的单片机调试断点到底应该怎么设置?| 颠覆认知


-THE END-



如果对你有帮助,记得转发分享哦


微信公众号「鱼鹰谈单片机

每周一更单片机知识

长按后前往图中包含的公众号关注

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存