允許的錯誤消息冒泡

我一直想從調用的函數返回的錯誤信息時，什麼是最好的做法是什麼？

在我創造我的共享庫之一，我有這樣的功能：

/* 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

允許的錯誤消息冒泡

回答

相關問題