【问题标题】:What should I return for errors in my functions in C?对于 C 函数中的错误,我应该返回什么?
【发布时间】:2011-01-14 02:31:00
【问题描述】:

目前,如果发生错误,我在 C 中的自定义函数中返回 -1,成功返回 0。例如,使用链表和某些函数需要一个非空列表才能正常工作。如果作为参数传递的列表为空,我返回 -1(错误),如果它不为空并且函数正常工作,则返回 0。

我是否应该返回 1 而不是 -1?

这是在 C 中做事的标准方式还是您推荐不同的方法?

【问题讨论】:

    标签: c error-handling return-value error-code


    【解决方案1】:

    返回一个非零值表示失败。这样你就可以这样编写函数调用:

    if(func_call())
    {
        doErrorHandling();
    }
    

    此约定将允许您使用任何!0 值来指示特定错误,这将允许您以统一的方式使用一个变量。所以上例中if的主体可以有一个switch语句来处理具体的错误。

    你可以用不同的方式来做——但如果你选择这样做的话,那就要遵守约定——不幸的是,win32 API(和我使用过的其他 API)混合和匹配约定。

    【讨论】:

    • 如果你没有任何特定的错误代码,你总是可以只返回一个布尔值。
    • +1 不一定是肯定的,不过,0 表示成功,!0 表示错误就足够了。事实上,根据我的经验,错误代码为负数更为常见。
    • @Steve:在某些适合的语言/环境中,但不是 C。0 = 成功在 C 文化中根深蒂固,您需要有一个 非常好的 i> 做其他事情的理由。
    【解决方案2】:

    听起来不错。 -1 用于 I/O 函数,因为正返回值通常表示成功,并且是已处理的字节数。如果您有多种方式可能导致函数出错,那么您可以返回不同的整数或设置全局错误变量(标准库使用 errno)来包含错误代码。

    就风格而言,我不希望返回状态码,因为这意味着我的函数不能(干净地)返回任何其他内容。相反,我会在调用函数之前检查输入。但这是主观的,取决于上下文。

    【讨论】:

      【解决方案3】:

      我建议您找到一种方法,在出现错误时,在所有信息仍然可用的情况下,格式化一个内容丰富的人类可读字符串,并设计一种方法来解决这个问题程序的其余部分,通过用户,他的手机,交给你的开发团队进行分析。

      在我看来,如果您想更快地生产出更好的软件,那么这似乎是任何设计的一个重要特征。中途杀死错误信息是大罪,C语言不是借口。

      【讨论】:

      • 向谁提供全面信息 - 最终用户还是开发人员???用什么语言???
      • 当然,为开发人员提供了充分的信息。再次阅读我的答案。语言:英文。开发人员应该懂英语。用户/帮助台应该能够尝试并将其转发给团队。
      【解决方案4】:

      有很多方案 - 但无论你做什么,始终如一地去做!

      如果您没有很多失败条件,只需使用 0 表示错误。那是因为错误测试的编写方式很简单:

      if (!list_insert(...)) { handle_error; }
      

      否则低于零的答案可以与正常答案 >= 0 一起使用。您可以将其用于列表长度等函数,在正常情况下不会为负数。或者,如果您想要许多错误代码(-1 - 不存在,-2 - 未找到,-3 ...,...)

      【讨论】:

      • 不要使用 0 表示错误。 C 有一个非常非常强大的历史:0 = 成功,!0 = 失败。正如 Hassan Syed 所指出的,Windows API 设计者未能认识到这一事实,这导致了无穷无尽的混乱。
      • 我认为这两种方法都没有什么大问题。有项目做 0==失败,也有其他项目做 0==成功。只要它被记录在案并且您在整个项目中保持相同的约定 - 没有办法是“错误的”。对我来说,它更容易阅读——“if not list_insert”,意思是 list_insert 失败。除非您希望您的功能在大多数情况下都会失败... Hassan 还指出它们混合和匹配不同的方式,(不是他们使用 0==error)并且基本上说了我开始的同样的事情 - 无论你做什么,坚持下去。
      猜你喜欢
      • 2012-12-04
      • 2019-09-18
      • 1970-01-01
      • 2018-09-03
      • 2010-12-01
      • 2019-07-08
      • 2011-12-28
      • 1970-01-01
      • 2020-02-06
      相关资源
      最近更新 更多