确定错误的原始原因

Question

C 中的嵌套错误处理是否有一些众所周知的模式/实践，例如 Java 中的嵌套异常？

通常的“只返回错误代码/成功”错误详细信息可能会在程序确定它应该记录/报告错误之前丢失。

想象一个类似这样的代码：

err B()
{
  if (read(a/b/c/U.user) != OK) {
    return read_error; //which would be eaccess or we could return even e_cannot_read_user
  }

  if (is_empty(read_user.name)) {
    // we could tell exactly what is missing here
    return einval;
  }
  ...
}

err A()
{
  if (B() != OK) {
    if (cannot_handle_B_failing()) {
      return e_could_not_do_b;
    }
  }
  ...
}

main()
{
  ...
  if (A() != OK) && (no_alternative_solution()) {
    report error_returned_by_A;
    wait_for_more_user_input();
  }
}

有没有人在这种情况下成功地尝试过在 C 中使用某种嵌套的错误代码/消息？可以报​​告（主要）用户名丢失或由于权限无效而无法读取文件 F 的事实。

是否有支持此类功能的库？

Answer 1

我建议你看看Apple's error handling guideline。它是为 Objective-C 设计的，主类是NSError。他们使用userInfo 字典（映射）来保存有关错误的详细信息，并且如果需要，他们已经预定义了NSUnderlyingErrorKey 常量来保存该字典中的底层NSError 对象。

因此您可以为您的代码声明自己的错误struct 并实施类似的解决方案。

例如

typedef struct {
  int code;
  struct Error *underlyingError;
  char domain[0];
} Error;

然后您可以使用domain 字段对错误进行分类（根据需要按库、文件或函数）； code 字段用于确定错误本身，可选underlyingError 字段用于找出导致您收到错误的潜在错误。

Answer 2

每个函数都可能有自己独立的、记录在案的、孤立的错误集。就像 libc 中的每个函数都有自己记录的可能返回值和 ERRNO 代码集。

“根本原因”只是一个实现细节，你只需要知道它失败的“原因”。

换句话说，A 的文档不应该解释 B，不应该告诉它使用 B，也不应该告诉 B 的错误代码，它可以有自己的、本地有意义的错误代码。

此外，在尝试替代方案时，您必须保留原始故障代码（本地），因此如果替代方案也失败了，您仍然能够知道是什么导致您首先尝试它们。

err B()
{
  if (read(a/b/c/U.user) != OK) {
    return read_error; //which would be eaccess or we could return even e_cannot_read_user
  }

  if (is_empty(read_user.name)) {
    // we could tell exactly what is missing here
    return einval;
  }
  ...
}

err A()
{
  if ((b_result = B()) != OK) {
    // Here we understand b_result as we know B,
    // but outside of we will no longer understand it.
    // It means that we have to map B errors
    // to semantically meaningful A errors.
    if (cannot_handle_B_failing()) {
      if (b_result == …)
          return e_could_not_do_b_due_to_…;
      else if (b_result == …)
          return e_could_not_do_b_due_to_…;
      else
          return e_could_not_do_b_dont_know_why;

    }
  }
  ...
}

main()
{
  ...
  if ((a_result = A()) != OK) && (no_alternative_solution()) {
    // Here, if A change its implementation by no longer calling B
    // we don't care, it'll still work.
    report a_result;
    wait_for_more_user_input();
  }
}

将 B 的错误映射到 A 的错误的成本很高，但有好处：当 B 更改其实现时，它不会破坏 A 的所有调用站点。

这种语义映射起初可能看起来毫无用处（“我会将“权限被拒绝”映射到“权限被拒绝”...），但必须适应当前的抽象级别，通常来自“无法打开”文件”改为“无法打开配置”，例如：

err synchronize(source, dest, conf) {
    conf_file = open(conf);
    if (conf == -1)
    {
       if (errno == EACCESS)
           return cannot_acces_config;
       else
           return unexpected_error_opening_config_file;
    }
    if (parse(config_file, &config_struct) == -1)
        return cannot_parse_config;
    source_file = open(source);
    if (source_file == -1)
    {
       if (errno == EACCESS)
           return cannot_open_source_file;
       else
           return unexpected_error_opening_source_file;
    }
    dest_file = open(dest);
    if (dest == -1)
    {
       if (errno == EACCESS)
           return cannot_open_dest_file;
       else
           return unexpected_error_opening_dest_file;
    }
}

它不一定是一对一的映射。如果您一对一映射错误，对于三个函数的深度，每个调用三个调用，更深的函数有 16 个不同的可能错误，它将映射到 16 * 3 * 3 = 144 个不同的不同错误，即只是每个人的维护地狱（想象一下您的翻译人员也必须翻译 144 条错误消息......并且您的文档列出并解释了所有这些，对于一个单一的功能）。

所以，不要忘记函数必须抽象他们正在做的工作以及他们遇到的错误抽象，到一个可理解的、本地有意义的、一组错误。

最后，在某些情况下，即使保留对所发生事件的完整堆栈跟踪，您也无法推断出错误的根本原因：假设配置读取器必须在 5 个不同的位置查找配置，它可能会遇到3个“找不到文件”，一个“权限被拒绝”，另一个“找不到文件”，所以它会返回“找不到配置”。从这里，除了用户之外，没有人能说出失败的原因：也许用户在第一个文件名中输入了错字，而权限被拒绝是完全可以预料的，或者前三个文件不应该存在，但用户做了一个 chmod第四次出错。

在这些情况下，帮助用户调试问题的唯一方法是提供详细标志，例如“-v”、“-vv”、“-vvv”……每次添加新级别的调试详细信息，直到用户能够在日志中看到配置有 5 个要检查的位置、检查第一个位置、找不到文件等等，并推断出程序偏离其意图的位置。

Answer 3

我们在其中一个项目中使用的解决方案是通过完整的函数堆栈传递特殊的错误处理结构。这允许在任何更高级别上获取原始错误和消息。使用此解决方案，您的示例将如下所示：

struct prj_error {
    int32_t err;
    char msg[ERR_MAX_LEN];
};

prj_error_set(struct prj_error *err, int errorno, const char *fmt, ...); /* implement yourselves */

int B(struct prj_error *err)
{
    char *file = "a/b/c/U.user";
    if (custom_read(file) != OK) {
        prj_error_set(err, errno, "Couldn't read file \"%s\". Error: %s\n",
            file, strerror(errno));
        return err->err;
    }

    if (is_empty(read_user.name)) {
        prj_error_set(err, -ENOENT, "Username in file \"%s\" is empty\n",
            file);
        return err->err;
    }
    ...
}

int A(struct prj_error *err)
{
    if (B(err) != OK) {
        if (cannot_handle_B_failing()) {
            return err.err;
        }
    }
    ...
}

main()
{
    struct prj_error err;
    ...
    if (A(&err) != OK) && (no_alternative_solution()) {
        printf("ERROR: %s (error code %d)\n", err.msg, err.err);
        wait_for_more_user_input();
    }
}

祝你好运！

Answer 4

这不是一个完整的解决方案，但我倾向于让每个编译单元（C 文件）都有唯一的返回码。它可能有几个外部可见的函数和一堆静态（仅在本地可见）的函数。

那么在 C 文件中，返回值是唯一的。在 C 文件中，如果有意义，我还决定是否需要记录一些内容。无论返回什么，调用者都可以确切地知道出了什么问题。

这些都不是很好。 OTOH 异常也有皱纹。当我用 C++ 编码时，我不会错过 C 的返回处理，但奇怪的是，当我用 C 编码时，我不能直截了当地说我错过了异常。它们以自己的方式增加了复杂性。

我的程序可能如下所示：

^some_file.c:

---

static int _internal_function_one_of_a_bunch(int h)
{
   // blah code, blah
   if (tragedy_strikes()) {
       return 13;
   }

   // blah more code
   return 0; // OK
}

static int _internal_function_another(int h)
{
   // blah code, blah
   if (tragedy_strikes_again()) {
       return 14;
   }

   if (knob_twitch() != SUPER_GOOD) {
       return 15;
   }

   // blah more code
   return 0; // OK
}


// publicly visible
int do_important_stuff(int a)
{
    if (flight_status() < NOT_EVEN_OK) {
        return 16;
    }

    return _internal_function_another(a) ||
           _internal_function_one_of_a_bunch(2 * a) ||
           0; // OK
}