我正在構建將在兩種類型的應用程序中使用的數據訪問層。數據訪問層中的異常處理策略
不關心錯誤細節的應用程序。如果發生異常，那麼很可能只是記錄下來，用戶可能不知道它。
例如：簡單的條碼存貨申請。用戶輸入條形碼，並且如果數據庫可用連接，則系統提供一些額外的信息，如果不是，則只有條形碼被本地記錄。在這種情況下，我不想進行細節異常處理。
應用程序，我非常關心例外的細節。
構建我的DAL以適應這兩個類別時，我必須遵循什麼策略？
現在我正在構建一個來自第一類的應用程序，我在DAL方法中完成的所有工作就是讓異常起泡到表示層，其中我有幾個try..catch塊，以便進行簡單的處理記錄，讓用戶不知道他的錯誤。
錯誤處理是從知道的部分代碼中知道需要知道的人的信息。 DAL知道如何打印SqlException，SqlCommand和SqlParameters集合的蹤跡。但是UI知道導致異常的整個調用堆棧。用戶可能不知道如何處理這些信息，因此您應該登錄到單獨的頻道，例如發送給開發人員的電子郵件或數據庫中的日誌。
如果您正在寫錯誤記錄器，我還會推薦使用真正的應用程序（或多個真實應用程序）作爲您的庫的測試。例如，您可以將錯誤記錄器連接到codeplex上的各種應用程序，並查看錯誤故障排除的難點，或嘗試dogfooding，並使用錯誤記錄器記錄錯誤是您自己的庫。
所以你說不要試圖捕捉所有東西（通過在每種方法中放入try catch），並且嘗試在最高級別捕獲excpetion，因爲我有整個堆棧跟蹤來查看所有基礎級別。正確？所以在我的情況下，因爲我有一個dal和一個表示層，所以我將不得不在演示文稿中這樣做，因爲我現在正在做它... – e4rthdog
是的，錯誤日誌記錄通常最好在堆棧頂部完成。但是，在引發錯誤之後，您仍然可能會捕獲並重新拋出新的錯誤或執行庫特定的日誌記錄。在C＃中，拋出throw的區別;與投擲新的XXX;後者將trucate調用堆棧，前者不會。 – MatthewMartin
我使用[Elmah]（https://code.google.com/p/elmah/）記錄所有拋出的異常，我推薦它，這是真的使用，並且沒有必要在每種方法中放置try/catch 。 – Juanito
您的DAL不應該關心它是如何被消耗的。讓它拋出有意義的異常，讓你的消費層/應用程序處理，但他們認爲合適。這聽起來像你使用的策略已經考慮到了這一點，所以我認爲你不需要改變任何東西。 –
避免使用異常來控制程序流。用它們來表示一個並非預期的特殊情況。這意味着您的DAL將決定何時保持連接可用時的數據。 – MushinNoShin
@EliGassert：這意味着在演示文稿或製作某種自定義異常處理類中的多個嘗試catch塊... MushinNoShin：有些情況下數據永遠不可用（例如，如果3G網絡出現故障並且平板電腦無法連接） – e4rthdog