如何对我的自定义错误编号

Question

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

我应该返回什么错误值，以便它们不会与现有错误值发生冲突。还是我把整个事情都搞反了？

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

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

Answer 1

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

Answer 2

我应该返回什么错误值，以免它们与现有错误值发生冲突。还是我把整个事情都搞反了？

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

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

• 0 - 正常，
• 1 - 内部但可能可恢复的错误（例如内存分配错误，终止其他批处理并尝试重新启动），
• 2 - 配置中的致命错误（重启不会有帮助），
• 3 - 输入数据出现致命错误（替换输入，重试），
• 4 - 输出出现磁盘已满错误（clean /tmp，重试）。

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

Answer 3

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

无论如何，这里是关于它的一个有趣的讨论。

Answer 4

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

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 中设置的错误代码和字符串。

Answer 5

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

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