共享錯誤處理代碼的設計模式

我正在尋找一些關於調用API中的方法的代碼的體系結構的想法/意見。在我的情況下，調用代碼是C＃/。NET和API是非託管傳統DLL的一部分。但同樣的問題可以適用於許多不同的語言/環境。共享錯誤處理代碼的設計模式

我基本上是圍繞非託管API編寫託管包裝。包裝器用於處理非託管代碼的封送處理，並將低級錯誤和異常轉換爲託管異常。

以下圖案頻繁發生，即，用於在API中的每個函數：

public void CallMethodX(<params>) 
{ 
    try 
    { 
     API.MethodX(<params); 
     <common code for checking for error conditions in API; convert to exceptions and throw> 
     <common code for logging API call> 
    { 
    catch (SEHException xx) 
    { 
     <common code for querying API for more info on error and creating new managed exception> 
    } 
}

還要注意：各種API方法可以有不同的簽名。

最基本的問題是：人們建議如何抽象出日誌和錯誤處理的通用代碼。即使在最好的情況下，即通過將通用代碼移動到靜態效用函數中，每個API方法調用周圍都有很多重複的樣板代碼。

，我已經有一些想法包括：

移動普通代碼工具類，它接受的實際方法的委託和注入委託到實用程序類。該實用程序類然後執行實際的異常處理和日誌記錄。 [工作正常，但創建/傳遞委託變得笨拙/醜陋]。
使用命令模式。 [會很好地工作，但似乎很多增加複雜性只是爲了共享代碼]

任何其他的想法？最佳的面向對象的做法是在哪裏放置通用的異常處理代碼？請注意，我不想將處理程序代碼放在調用堆棧上方，即將其定位到調用我的圖層的客戶端 - 因爲該圖層應與查詢API的詳細信息完全分離以獲取詳細的錯誤信息並轉換爲託管的例外。

來源

2010-07-07 Sean Sexton

你可以看一個解決方案是Aspect Oriented Programing。這是AOP設計的問題類型。不幸的是，很多語言不支持AOP，但如果你是谷歌的C＃面向方面編程，你會發現它是可行的Aspect Oriented Programming Using .Net

來源

2010-07-07 11:39:43

是_'hack在一個語言特性與程序集injection_'真的是一種設計模式？ – Gusdor 2014-09-09 07:09:16

共享錯誤處理代碼的設計模式

回答

相關問題