C++错误管理

1.

如何定义错误代码或者是error 号？

一般用宏定义统一定义error号，遇到不同模块，以及防止自己定义的error错误号和其他人相同，如何处理这些冲突？

Answer: 对于系统API， C/C++标准库API， #include 里已定义了错误码。

自己实现的函数，如果要定义不同于errno.h里的错误码， 错误码的值要以用一个偏移量实现， 例如：

#define OFFSET 1000

#define ERR_XXX (OFFSET + 1)

2.

哪些表达式或者函数返回值需要判断？

Answer: 只要函数的返回值不为void，就需要判断。表达式里，直接调用函数的情形

比较少， 如果有，当然要检查返回值。这是一个优秀的程序员必需的习惯。

3.

大家都有自己的专门的错误管理模块来专门处理错误状态以及提示吗?

Answer: 一般用errno.h，因为时面的错误码足够用。

如何精准的定位出错误的出处(例如可以迅速的定位是哪一行哪一个函数出错)。

Answer: 本人习惯用调试信息输出, 例如：

C/C++ code

#define DEBUG

#if defined(DEBUG)

#if defined (__KERNEL__)

debug_info() printk()

#else

debug_info() printf()

#endif

#else

debug_info()

#endif

debug_info(“Debug: into %s, %s, %d\\n”, __FILE__, __FUNCTION__, __LINE__);

4.

一般在实际工程项目中, 错误处理可能不需要处理的那么细.

#define ERR_CODE_BASE xxx

#define ERR_CODE_APP1 ERR_CODE_BASE + 0

#define ERR_CODE_APP2 ERR_CODE_BASE + 1

如果出错了，需要分别处理, 那就定义不同的返回码, 函数返回后分别处理.

如果出错了，不需要分别处理，就直接返回-1. ……

5.

一般来说，定义函数的返回值应该是bool或int，这样便于处理函数执行是否成功.特别是接口里的函数. 每个模块有自己的错误代码定义，然后接口返回值统一定义。

6.

个人感觉用日志最清晰，如果是GUI的话用提示框是个不错的选择,不过日志太多会降低系统效率.

7.

首先要提高代码质量。

1.将编译时的编译选项设置为打印所有告警信息，并将告警作为错误来处理。

2.pc-lint进行静态检查，清除所有错误。

3.用purify 进行运行时的检查。

4.做好单元测试，比如cppunit ,gtest.

5.编译时，加上-g，在coredump的时候，能够将信息保存下来。

6.做好日志模块，日志模块分等级，并且记录日志的文件和行号。

7.规划号返回的错误信息.

这一项个人感觉比较好,就是实际项目中,警告可能很多很多,实施起来工作量比较大.

8.

我习惯将所有模块的错误码都放到一个文件中去定义，加上前缀可以区分的比较清楚；写一个专门的log模块，分level来打日志，加上这些宏和时间，还有上下文的log，基本上就能定位错误的原因了.

1. 一般定义的是枚举，枚举名有特定的前缀

2. 目前还没有什么好的建议，我们一般是检查那种可能会越过边界值的表达式的值，函数返回值主要可能会严重影响结果的时候才检查。

3. 项目中日志模块来处理错误及提示

4. 利用__FILE__, __FUNCTION__, __LINE__来定位错误的位置

9.

我公司就是 日志 + TRY CATCH

然后再定义一个错误管理类CERROR 将所有的错误保存在这个类中实现 就不需要反复定义 宏了. 在定义一些宏来处理一些复杂的多个错误输入方法提高程序效率

10.

1、一般就看它的作用范围，如果在多个模块中都是用到，可以考虑提取出来放到单独的文件中去，如果只在一个模块中使用到，那在局部添加就可以了。

2、一般用含有错误描述意义的字符，通过宏定义描述即可，直观。

3、调试时，可以通过判断函数的返回值、trace、assert、断点等方式跟踪，甚至可以通过AfxMessageBox输出消息框跟踪(此方法用的溜了也是个很不错的方法哦)。

11.

规则1、系统调用是必须要检查错误的，一般分为可处理异常（比如信号中断），资源异常（比如内存暂时不够），硬件异常（比如文件系统损坏），分门别类对这些异常进行处理。有些异常是软件无法处理的，比如硬件异常，那么只能构建相应的日志系统来记录。

规则2、如果是参数错误，比如检查传入的函数参数不合法，那么一般都是放弃处理或者将非法参数强制转换成默认的合法参数，并告知调用者。

规则3、处于底层，被反复调用的函数，需要高效运行的，一般不做参数检查，在函数头里写清楚注意事项。

这3各规则写的相对清楚, 详细和底层.

12.

哪些表达式或者函数返回值需要判断？

暂时先仅对这个问题发表一下我的看法。

如果一个表达式或者函数调用，存在失败的可能性，无论是其抛出异常还是错误返值，都必须进行错误处理。只不过异常和错误返值地捕获方式不同，导致了两种错误处理的形式可以不同。对于异常，我们可以一并捕获多条语句产生的异常，而对于错误返值，我们必须要逐个处理。在同一个程序或者模块中，要保持一致的错误处理方式，要么使用异常要么使用错误返值，对于模块内不同的错误处理方式，即边界，需要进行方式转换。

无论如何，你所看到的代码，错误处理都会占有一个相当的比例，这是很正常的，这也说明了编写程序的人的缜密思维以及体现了程序的健壮性。这里所讲的，排除那些对于程序理解不足，而导致的不必要的错误处理。

最后，只要程序有失败的可能性，必须进行错误处理。

13.

1.如何定义错误代码或者是error 号？

一般用宏定义统一定义error号，遇到不同模块，以及防止自己定义的error错误号和其他人相同，

如何处理这些冲突？

>>>>>>系统调用使用errno，其他的话，采用宏定义，一般OK都是定义为0，出错定义为负值，正值一般用于返回该函数拥有的其他意义。错误值宏定义是全局的，各模块自己估计需要多少个，然后全局分配。数据类型一般都是int的，数值范围足够挥霍了。

2.哪些表达式或者函数返回值需要判断？

说道这一点，我曾经看过一段代码，该代码对几乎所有的表达式或者函数的返回值或者结果都进行了判断，

俨然变成了一个出错检查的代码。

>>>>>>>>>>>>>>>奇怪了，为什么不对返回值或者结果进行判断？例如一个函数定义了几个返回值，那就表示它执行的时候是有可能遇上这些错误情况的。所以通常的建议应该是鼓励编程者判断返回值，然后给出例外情况：1、编程者明确知道该函数不会有全部或者某些错误返回，而这个“明确知道”应该来源于系统架构、概要设计等的明确提出的设计约束所推导出的。2、调用本模块内自己的函数，可以不坚持检查返回值，因为一般根据本模块的设计所做的代码，你应该是很清楚地，或者本模块的函数就是你自己写的，错误处

理应该在设计中已经明确，所以这时候你不检查返回值一般也没人有异议。其实这也符合了第1点的。这两点对设计和编程者的水平有较高要求，执行和代码审查的时候自己看着办吧。

例如我看见过，有些代码仅仅改了一下运行环境，就出错误，大家就得费时费力挑错，而很可能当初编程时把这些错误情况就懒得处理了。

3。大家都有自己的专门的错误管理模块来专门处理错误状态以及提示吗?

>>>>>>>>>>没有吧。你说的错误管理模块的职责是处理错误状态，以及出错提示？专门搞这样一个模块，貌似没怎么见到过。处理错误状态应该是各模块自己的事，出错提示么，要什么提示？编译时报错、控制台报错、弹出框……想用什么用什么。

4.精准的定位出错误的出处(例如可以迅速的定位是哪一行哪一个函数出错)。

__FILE__ __LINE__ __FUNCTION__

assert

都可以定位了

这位貌似是一位特别厉害的大侠,也比较实际.自己理解比较深.

总之, 学习了.最后说一下自己的想法,我是一个菜鸟,基本调试跟踪还会点,但是每次出错了,基本都是根据错误提示来修改的,再不然就是在某一条可能出错的语句输出,在MFC中,会

用MessageBox来推测,警告一般没管过.针对以上大侠的建议,学习了,不过log这个东东还没学会,公司貌似也用的log和SIZE.在学习中. 总结一下也让大家看看.(声明:本文参考CSDN汇总)