【2022-04-18】 浅谈由window异常处理方法转向Linux下的异常编程处理

后端服务器开发经验分享

在开发Windows程序时

我们在开发Windows服务器时，除了在开发阶段尽可能的处理掉“程序异常”时，经常会遇到程序在客户机上跑时，各种各种奇葩的未经处理的异常，导致我们的程序core dump； 可以看下， Windows下C++异常处理，也可以看下《Windows核心编程》中有专门一章对齐进行解释。这种情况下，必须要求服务器对常用的异常进行“捕捉”、“分析”、“过滤“、”处理”；根据经验，通常可做以下一些操作：

• 忽略异常；
• 执行异常处理代码后，局部恢复动作；
• 程序进入异常结束流程，记录运行堆栈、出错信息等；
• 由其他看门进程执行复位、重启等操作；

---

转向Linux程序开发

我们开发Linux程序服务时，我们的服务程序主流程通常都是由以下特点：

• 服务器运行在后台；
• 服务器需要7*24运行，需要保证长时间的稳定运行；
• 服务器运行期间，发生的程序异常，可能前台无法感知；

针对第3点，我们可以通过应用层的心跳保持，来显示服务的监控状态，阿里的Nacos系统服务注册管理机制就是用的这个，可以参考Nacos描述。

Linux下需要处理的异常（又叫特殊信号处理）

Linux下我们需要关注的信号有：

• SIGHUP：控制终端挂起
• SIGINT: 键盘输入的中断，例如Ctrl+C
• SIGABORT： 进程调用abort函数时，产生的信号
• SIGSEGV: 非法内存使用
• SIGPIPE: 往已经关闭的管道或者Socket中写数据
• SIGALARM： 由alarm或者settimer设置的实时闹钟超时引起
• SIGTERM: 终止进程，例如kill命令发送的信号
• SIGCHLD： 子进程的状态发生变化（退出或者暂停）
• SIGURG： socket连接上收到紧急数据

---

前言

主要讲述网络编程中常用的SIGHUP、SIGPIPE、SIGURG

一、信号处理函数

具体实现代码可以参考网络资源，比较简单

二、重点讲述SIGPIPE

通常情况下，开发的网络通信程序，往一个读端已经关闭的管道或者socket中写数据的时候，讲引发SIGPIPE信号。我们需要在主流程中进行捕获并处理，否则它的默认动作将会执行进程终止。这种情况在实际开发过程中，会经常遇到，并且对于我们长期运行的后台服务器程序是致命的。

• 这个问题在前端时间使用SRS流媒体服务器时，也曾遇到，当时的做法是讲超时时长设置到足够大，那么socket不会因为超时而关闭。rtmp超时中断场景解决，如何增加srs配置文件conf的配置项
• 正常做法，可以忽略它，或者判断一下是否真的关闭，调用后续回收流程。

后续我会将我封装的代码贴出来。欢迎大家跟帖。