在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
这样，在程序中能够非常好的控制开关。提高效率