允许的错误消息冒泡

我一直想从调用的函数返回的错误信息时，什么是最好的做法是什么？

在我创造我的共享库之一，我有这样的功能：

/* Create directory structure */ 
apr_status_t dir_create(apr_pool_t *mem_pool) 
{ 
#define SRC "test_src" 

    apr_fileperms_t file_perms = 
     APR_FPROT_UWRITE | 
     APR_FPROT_GWRITE | 
     APR_FPROT_WWRITE | 
     APR_FPROT_UREAD | 
     APR_FPROT_GREAD | 
     APR_FPROT_WREAD | 
     APR_FPROT_UEXECUTE | 
     APR_FPROT_GEXECUTE; 

    if(apr_dir_make(SRC, file_perms, mem_pool) != APR_SUCCESS) { 
     LOG_CRIT("Failed to create directory"); 
     return FALSE; 
    } 

    return TRUE; 
}

的LOG_CRIT将显示与错误号相应的错误消息。

在我的应用程序，它会调用这个函数我有这样的：

if(dir_create(mem_pool) != TRUE) { 
    return 1; 
} 
LOG_INFO("Directory has been created");

对于例如，当上面的失败，会记录是这样的：

[CRITICAL] dir_create:28: error [File exists] Failed to create directory

我想知道我应该把调用库函数的应用程序中的错误消息。或者，您应该在最早的时候尽快显示错误信息？

在上面的情况下，我在被调用函数中显示错误消息。当函数返回时，我只返回1来结束应用程序或做其他事情。

另一个想法是，最好是返回错误指示符，并让调用函数显示错误的来源？

来源

2013-04-23 ant2009

一些选项，变得越来越疯狂 - 你可能有什么适合你的情况;-P这更加刺激你的选择意识的本能：

捕捉尽可能多地认为明智的 - __FILE__ ，__LINE__，errno，错误描述，操作正在尝试，参数，结果等 - 上线检测到错误
原则：只做来电要你做什么;不同的妥协方法很多：
- 返回一个小的，容易测试的数据值（数字或指针），但提供一些访问函数来获取上面捕获的其他信息很容易，所以你“回到”的代码可以做任何事情像...
  - eg调用者可能会取消引用该指针以获取错误详细信息，类似于函数，调用者给出指向可打印错误消息的指针（如果调用者不需要该消息的含义的可见性）...
- 立即通知一个调用者控制的例程，它可以在调用者认为合适时抑制或重定向错误;例如您的图书馆可以提供一个指向你调用一个函数，调用者可以重定向 - 默认可以登录到标准错误或其他一些通常acceptible行动
- 设计你的库代码是#include d，并使用调用者提供的预处理器宏观规制的错误处理行为
- 硬编码输出，但让呼叫者修改流这可能如果需要

您需要如果使用你的库的应用程序是这样的，那么就更加认真对待这种事情想要尝试性地尝试操作（例如，故障切换或事务语义），特别是如果某些错误行为具有不可逆转的后果（例如，一些批处理作业系统考虑的工作已经失败，如果是印在标准错误什么 - 但是从程序的角度看你的库函数可能不构成故障，或爆裂打开一个图形错误对话框会挫败无人值守的操作）。

来源

2013-04-23 08:33:19

我建议您尽可能在最低级别记录错误消息，因为您在此处执行此操作。如果您需要访问errno，这一点尤其重要，否则在您进入更高级别功能时可能会发生变化。在这个级别上，我会尽可能地将错误信息作为技术和特定信息。

根据您的库函数的返回值，您的应用程序代码可能会采取一些操作（例如，它可能会显示一个弹出窗口，提供错误的可读描述，或者可以写入stderr）。如果你愿意的话，通常可以在最高级别上完成 - UI级别。

来源

2013-04-23 07:50:12 sapi

允许的错误消息冒泡

回答

相关问题