异常与错误代码与断言

18 c++ error-handling assert exception

我正在开发一个生成设备报告的库.generate_report (const std::string& no)由于各种原因,成员函数可能会失败:

  1. 报告号无效.
  2. 无效状态(report_generator是FSM)
  3. 没有设备处于活动状态
  4. 报告生成期间出错

哪种错误处理机制最适合这些错误?

  • 只是回来truefalse
  • 返回错误代码
  • 断言并记录
  • 抛出异常
  • 以上的任何组合

一些上下文信息:正常的工作流程如下.用户激活设备,从列表中选择报告并单击"生成".

编辑:感谢您的回复!对我来说,现在很清楚何时使用断言以及何时进行错误处理.至于错误处理,错误代码和异常都有利有弊.我想我会考虑异常(并为上述错误创建四个类),但我还不确定.我总是想到"意外情况"的例外情况.无效的报告编号并非真正意外.有什么建议?:)

RED*_*AIR 12

其中任何一个都有不同的目的:

  • 错误代码vers.exception(s):异常和错误代码表示如何处理结果代码的不同习惯用法.异常更加健壮 - 结果代码可以被忽略或丢失.库通常应该强烈区分抛出的异常/异常,以及何时使用错误代码.充其量,根本不使用其中之一.

  • return truefalse:错误代码的特化.通常是最糟糕的想法 - 只有在没有更多报告而不是好或坏(即malloc返回好或坏(= NULL)时才有好处.

  • assert和log:这些是调试技术,不应该用作用户/客户端的报告机制.断言只是说"事情发生了,我无法处理 - 我放弃了".


Ed *_* S. 11

断言不是正确的选择.当你有一个不变量时使用断言; 应该永远不会发生的事情.如果它是一个错误条件而不是一个不变量,那么不要像assert()这样的东西,即参数永远不会为null.

如果是我,我会在界面中使用异常,如果必须的话,如果他们不使用异常,则通过内部使用的函数来转换错误代码.只是保持一致(并且不要使用assert这个东西).


Mar*_*age 5

与真/假和错误代码相比的例外有几个重要的优点:

  • 例外情况不容忽视.如果您的代码抛出异常,则调用者必须捕获它以避免出现未处理的异常.
  • 可以在比直接调用者更高的级别处理异常.如果使用错误代码,最终可能会导致应用程序的所有层都必须检查错误并将其传递回调用方.

断言用于表示代码中的前提条件,并希望在开发过程中发现任何错误.但是,您不应该依赖于发布代码中的断言,并且出于性能原因,断言通常会从发布代码中删除.


小智 2

选择什么策略通常取决于品味。我说选择最适合您图书馆客户的产品。如果他们采用例外策略,就使用例外。如果他们习惯了错误代码,请坚持使用。