在C/C++大型项目中，错误管理在项目中起着举足轻重的作用，以我自己的项目经验以及观摩其他项目，错误管理对项目框架以及开发效率有着很大的影响。对于错误管理的认识大致分为三类：
- 刚刚开始写程序的新手，满篇程序看不到一处关于返回出错的处理，更不用说出错管理了。说明他没认识到出错管理的重要性
- 程序中到处都能看到关于出错的处理。认识到了错误，但是处理方式欠缺
- 程序中几乎不会很明显的看到关于错误的处理。这是错误管理的最高境界。
错误管理，涉及到程序的健壮性，可恢复性，可靠性，高效性。在出错的情况下，程序任然能够相对稳健高效的执行。
下面我谈谈我自己在C/C++项目开发中关于错误管理的经验。
对于C/C++系统API，都提供了errno.h头文件，里面已经定义了绝大多数系统已知的错误以及其对应的错误提示。 参考《linux中出错处理》
一般系统自带的错误定义以及出错提示都不能很好的满足实际的项目需求，毕竟项目中很多都涉及到具体业务，如果笼统的使用系统定义的错误号以及描述，并不能很快的定义错误位置。通常需要我们自己重新封装并定义错误。
《The Art of Unix Programming》中有一个原则说的非常好：Rule of Repair: When you must fail, fail noisily and as soon as possible。当程序遇到无法修复必须报错的时候，就让它立即用很明显的方式报错。这句话很简洁，但是缺描述出了关于错误管理的理念。如果一定要出错，就很明显的方式来表达，目的就是为了很迅速精准的定位错误。出错不是期望，出错管理也不是目的，目的是为了在出错之后能很快的定位错误使得程序能够很快的恢复。
为了快速定位错误，有三个宏非常有用：
__FILE__ //文件名 __FUNCTION__ //函数名 __LINE__ //当前行号
一般针对不同的业务会有不同的模块。自定义错误号的方式如下：
//EBASE最高位是1，保证错误号是负数，符合编程习惯 #define EBASE 0X80000000 //串口业务模块 #define ESERIAL EBASE + 0XC8 #define ESERIALTIMEOUT ESERIAL + 1 //串口超时 #define ESERIALREAD ESERIAL + 2 //读串口错误 //.... //HTTP业务模块,与ESERIAL之间有200的差距，这样串口业务模块可以有200个错误号 #define EHTTPSERVICE EBASE + 0X190 #define EHTTPTIME EHTTPSERVICE + 1 #define EHTTPGET EHTTPSERVICE + 2 //... //与EHTTPSERVICE有200差距，这样HTTP也可以有200个错误号 #define EGSM EBASE + 258 //....
模块化定义错误，通过错误号区间可以很快的查阅错误模块。例如错误号是 -202，通过对照，毫无疑问是串口模块出错了。
接下来就是错误的翻译了。所谓错误翻译就是将错误号翻译成具体的语句。可以选择将错误描述与错误号写入Excel表中，然后导出XML文件，在程序中错误描述可以直接解析对应XML中错误号的描述即可。
另一种比较常见的方式就是直接用宏写在一个头文件中。当然，__FILE__, __FUNCTION__这些必不可少。
日志文件记录了程序后台运行状况以及出错前一刻程序正在做什么，一般可以从日志文件的数据分析程序的行为并定位错误。对于日志文件，我想C/C++程序员都会写，这里我就不多说。一般打印错误提示的同时都会伴随着写日志。
一般都会用宏来写打印错误和写日志的操作，关于如何写我这里不多说，我想很多人都会。这里我想强调的事关于打印错误信息和写日志一定要设置开关。在实际项目中，我经常会遇到这种问题，当有很多地方都需要打印和记录log的时候，程序执行的非常慢，当我把写日志去掉，程序立马就能很快的运行。所以，设置开关是很有必要的：
#ifndef LOG_OFF #define WriteLog(file, line, function, desc) \ //...一些写日志和打印操作 #else #define WriteLog(file, line, function, desc) #endif
这样，在程序中可以很好的控制开关。提高效率