C/C++项目中异常和错误管理

      在C/C++大型项目中，错误管理对项目开发效率和维护有着很大的影响，在项目中的地位也不容忽视。

     程序中的错误，一般可分为：可处理异常（比如信号中断）、资源异常（比如内存不足）、硬件异常（比如文件系统损坏）以及其他不可修复的错误等等。这些大部分异常都可以进行管理和处理，但有些异常是软件无法处理的，只能通过日志系统来记录。

      目前，以我自己在项目中的经验和对其它项目的观摩，对于错误管理的认识大致分为三类：

1. 刚入门写程序时，满篇代码中看不到一处输入参数有效性的检测和关于返回出错的处理等，更谈不上错误管理。
2. 代码中到处都能看到关于出错的处理，但是很混乱，这些出错的处理，更倾向于对代码中错误的检查。
3. 程序中几乎不会很明显的看到关于错误的处理。

      目前，偶停留在第2阶段，

      在Linux系统中，对于C/C++系统API，在errno.h头文件中提供了错误标识码，里面已经定义了绝大多数系统已知的错误以及其对应的错误提示。 能满足一般项目开发需求。但是涉及的具体业务和一些领域的专业背景时，系统定义的错误标识码不能清晰描述错误信息和快速定位错误位置。这时，我们必须重新封装、定义错误信息。

   ————————————————————————

      下面是根据我的学习经验和其它资料，整理而成的一些关于错误管理方面的东东。

      1、一些错误处理规则

      01、系统调用必须要检查错误；

      02、如果是参数错误，比如坚持传入函数参数不合法，一般都是放弃处理或者用默认的合法参数替代非法参数，通知告知调用者；

      03、处于底层，被反复调用的函数，需要高效运行的，一般不做参数检查，在函数里注明注意事项即可；

      04、错误标识码一般通过模块化宏统一定义，防止与其他人的冲突；

      05、自己定义的错误标识码统一增加一个偏移量，以区别于系统的错误码；

      06、调用函数时，只要函数的返回值不为void，就需要判断。如果在表达式里调用有返回值的函数，也尽量检查返回值；

      07、如果是中断错误，尽量使用异常，把正常流程和异常处理从逻辑上分开；

      08、遇到错误，能继续的尽量继续，尽可能不影响使用，在日志中记录下当前错误；

      09、对于不可修复的错误，使用断言，提前退出，其他情况，尽量少使用断言；

      10、记录日志文件名和行号，方便定位；

      11、将所有的日志、调试信息、错误异常信息分模块、分级处理；

      2、一些示例代码：

      对于不同的模块，错误标识码自定义方式如下：

/* EBASE最高位是1，保证错误号是负数，符合编程习惯 */#defineE_BASE0X80000000/* 模块A, */#defineE_MODULE_AE_BASE + 0XC8#defineE_A_TIMEOUT     E_MODULE_A + 1 /* 超时 */#defineE_A_READE_MODULE_A + 2 /* 读取错误 *//* .... *//* 模块B,与模块A之间有200的差距，这样模块A可以有200个错误号 */#defineE_MODULE_B    E_BASE + 0X190#defineE_B_TIMEOUTE_MODULE_B + 1#defineE_B_READE_MODULE_B + 2/* .... *//* 模块C,与模块B有200差距，这样模块B也可以有200个错误号 */#defineE_MODULE_CE_BASE + 0X258/* .... */

    定义好模块的标识码后，接下来在使用过程中需要对错误进行翻译和日志的记录。

      未完待续。