知识点

异常处理机制
try：一个 try 块标识了一个将被激活的特定的异常的代码块。后跟一个或多个 catch 块。
catch：程序通过异常处理程序捕获异常。catch 关键字表示异常的捕获。
finally：finally 块用于执行给定的语句，不管异常是否被抛出都会执行。例如，如果您打开一个文件，不管是否出现异常文件都要被关闭。
throw：当问题出现时，程序抛出一个异常。使用 throw 关键字来完成。抛出异常意味着可以自定义异常消息，可以将异常处理的方法交给外部，内部只需要将异常出现时出现的原因（消息）告诉（比较简单的使用时throw(new ApplicationException(“字符串”))）外部就好了。

简单来说，对于一个可能出现问题的函数/过程我们用

try{
    内容

}catch(exception e)
{
   出现问题后我们的处理方案
}

问题&BUG

硬件设备不在身边，串口收发数据方面出现问题，根据描述可以将错误定位在以下几个方面：

  1. DLL函数调用出错
  2. 下位机数据发送太快，出现粘包
  3. 信号量或者互斥锁释放异常

过程及解决方案

  1. 过程
    询问另一个工程师发现是VC14动态库没有安装，安装了之后发现还是运行到调用动态链接库的部分会出错，之后用另一个Qt编写的C++动态库测试程序在虚拟机测试（原环境中因为运行库都装好了无法检测问题），可以运行。之后再用VS2019写了个C++程序发现在虚拟机中运行不了，提醒错误。同时在一个博客中发现了一个神器：Dependency Walker 。可以列出程序中的依赖链接库。
  • 结论：VC14运行库丢失。是因为我重写的DLL是在VS环境下写的，编译出来的DLL本身就需要很多依赖库
  • 解决方案：重新在VC6.0里面重编译DLL。
  1. 过程
    由于手头上没有设备，自己重新用C# 写了个模拟下位机动作的程序。上位机发送指令后下发现下位机连续发送两个包（第一个确认包，第二个数据包）经常会出现重包和粘包，由于大体逻辑已经固定了，时间比较赶，简单的处理了一下，成功。
  • 结论：自己写的框架有问题
  • 解决方案：重新下发重新接受数据包的指令，将下位机连续发送两个包中的第二个包忽略。由于有多个包，原本的用计数的方式逻辑上有点复杂，最后采取只要收到最后一个包就说明收包结束。同时增加一个工作日志，将自己收到的包数记录下来方便后续排查错误。
  1. 过程
    同样因为手头没有设备，为了更好的定位错误内容，在可能出现错误的地方用都用try进行异常处理一下，在最后可以很快的找到问题。
  • 结论：暂无
  • 解决方案：对每一个可能出现问题的函数语句用try进行处理一下，一旦出现错误就弹出消息框。

    心得体会

    写日志真的很重要，尤其是当同样的问题重复出现的时候就能很快的解决问题。
    以后用微软的东西真的要小心！！！程序的移植真的害死人，经常莫名其妙出现移植错误。最狗血的是连写个简单的C++程序特么的都需要一些支持库我都想吐了。怪不得用VC6.0比较流行，难用是难用但是干净啊，很多东西都不用担心没有装可以直接移植直接跑，简直不要太爽。