【问题标题】:Using EXIT_SUCCESS/FAILURE as API return value使用 EXIT_SUCCESS/FAILURE 作为 API 返回值
【发布时间】:2017-10-16 13:03:53
【问题描述】:

在您自己的库 API 中使用 EXIT_SUCCESS 和 EXIT_FAILURE 作为函数的返回值是否被认为是合理、良好的设计和良好实践?

示例软件是一个低级平台库,用于同一产品线的多个产品中,适用于大量编译器和目标平台。开发团队在这个问题上存在分歧。一些开发人员认为将 EXIT_SUCCESS 和 EXIT_FAILURE 中定义的值重用作为内部函数和库 API 中的返回值来指示库调用的成功或失败状态是一种很好的做法。定义和使用自己的返回值将被视为“过度设计”。

其他团队成员认为 EXIT_SUCCESS 和 EXIT_FAILURE 被明确设计为与 exit() 函数一起使用,并且用于其他目的是完全危险的。

您对此有何看法?

【问题讨论】:

  • ... 并且用于其他目的完全危险,如果您不认为EXIT_FAILURE == 1 并不危险

标签: c


【解决方案1】:

从 7.22 开始,关于 stdlib.h 中的宏:

EXIT_FAILURE

EXIT_SUCCESS

它扩展为整数常量表达式,可用作退出函数的参数,分别向主机环境返回不成功或成功的终止状态;

这就是这些宏的用途。如果您的函数正在向主机环境返回状态,那么使用这些宏就可以了。将它们用于任何其他目的都是不好的做法,因为这不是它们的预期用途。

请注意,库的调用者不是“宿主环境”(操作系统)。将这些宏用作库中的返回码,其他程序员将使用这些宏是不好的做法,因为这不是宏的预期使用方式。使用它们并不危险,但它很草率而且非常混乱。

同样地,让函数在成功/错误时返回真/假通常被认为是草率的,因为这不会提供额外的错误信息。

定义和使用自己的返回值将被视为“过度设计”。

这就是您实现专业库的方式。事实上的行业标准是使用与所有可能发生的错误相对应的库特定枚举类型,然后让每个 API 函数返回该错误类型。这使得调用者更容易编写错误处理。每个函数都需要记录所有可能的返回码。

【讨论】:

  • 感谢您对参考文献的精彩总结。我同意并相信我们可以据此做出决定。
猜你喜欢
  • 2010-11-14
  • 2019-10-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-08-09
  • 2023-04-07
  • 2013-09-24
相关资源
最近更新 更多