3

如果我的程序异常终止（通过 exit()），我会返回一个错误代码。对于标准情况，我只返回底层的 errno（例如，用于失败的 malloc 等的 ENOMEM）。但是，在某些情况下，由于我自己的原因，我不得不终止，而没有定义系统错误。

我应该返回什么错误值，以免它们与现有错误值发生冲突。还是我在做整件事？

编辑：如果我不清楚这个问题，我很抱歉。我不是在谈论枚举等（它们是定义错误代码的机制）。我说的是他们可以在不与标准值冲突的情况下采用的值范围。

我不知道的是程序只能返回 8 位状态。所以看起来@r 是正确的——它太小了，甚至无法容纳所有标准错误，更不用说我的自定义错误了。所以 1/0 是 :)

4

5 回答 5

5

返回码的宽度通常很小，例如限制为 8 位，因此很难在其中存储大量信息。真的，我不会为除了 0/1（成功/失败）之外的退出代码而烦恼，除非您的程序旨在用于 shell 脚本，在这种情况下，您可能只需要找出潜在的 shell 脚本可能需要检查的错误情况并区分它们（例如，“不匹配”与“搜索时资源耗尽”）。

于 2010-08-11T15:19:49.483 回答
3

我应该返回什么错误值，以免它们与现有错误值发生冲突。还是我在做整件事？

把事情简单化。对错误代码（也适用于普通函数）最重要的测试是调用者可以做些什么。我见过一些项目，人们为所有独特情况引入了数百/数千个错误代码，最终导致错误处理完全混乱（他们试图为每个函数/SQL 语句提供唯一的退出代码）。而那 - 错误处理 - 正是与退出代码有关的一方。

我个人对返回码的规则是确保它们对错误处理有用。举例来说，对于一个批处理程序，我可能会像这样偷看状态代码：

  • 0 - 好的，
  • 1 - 内部但可能可恢复的错误（例如内存分配错误，杀死其他批次并尝试重新启动），
  • 2 - 配置中的致命错误（重新启动无济于事），
  • 3 - 输入数据中的致命错误（替换输入，重试），
  • 4 - 输出得到磁盘已满错误（清理 /tmp，再试一次）。

这只是一个示例，强调应该从调用者的 POV 考虑错误代码，而不是被调用者。例如，如果完全/部分自动化不是目标并且用户无论如何都必须分析日志文件，那么返回 0 或 1 也足够了。

于 2010-08-11T16:15:51.200 回答
1

您是否考虑过使用枚举来定义错误代码？

无论如何，这是一个有趣的讨论。

于 2010-08-11T15:20:37.233 回答
1

有几种方法可以做到这一点。

1) 枚举 - 这可以通过以下方式完成。可以灵活地在需要时添加不同的错误代码并将它们放在一个组中。说出与用户身份验证、文件访问、API 错误等相关的错误。

enum
{
ERROR_GROUP_1 =100,// This gives 99 error codes for a particular group, can be initialised to negative value too.
GROUP1_1,
.
.
ERROR_GROUP_2 = 200
GROUP2_2,
.
.
and so on
};

2) 使用预处理器指令

#define ERROR_CODE_START 00000000L

#define ERROR_CODE_1 (ERROR_CODE_START + 1)

3) 负返回值作为 int 但这会很痛苦，因为值的参考应该有很好的记录。

4）您可以创建一个类似GError的结构。在每个 API 中传递对此结构的引用并填写它。如果它不为 NULL，那么调用者可以检查将在 API 中设置的错误代码和字符串。

于 2010-08-11T16:04:28.337 回答
1

在符合 Posix 的系统上，返回 0 到 255 范围之外的任何数字绝对没有意义。这是因为 wait() 系统调用只允许您拥有程序返回值的低八位（或者可能是 16位）。

在实践中，您可能只需要少量代码，可能只是 0 和 1。可以通过 stderr 以更有用（对人类）文本格式传达更多信息。

于 2010-08-11T16:32:50.317 回答