.NET中的錯誤代碼/消息管理的方法

尋找在多層應用程序中管理錯誤代碼和消息的建議/最佳實踐。具體如下：.NET中的錯誤代碼/消息管理的方法

應該在哪裏定義錯誤代碼？枚舉？類？
錯誤消息或與錯誤代碼相關的更多詳細信息如何？資源文件？枚舉值的屬性等？
如果您有一個由DAL，BLL，UI和Common項目組成的多層應用程序，例如，是否應該爲所有層提供一個龐大的代碼列表，或者代碼是否可以通過項目/層擴展？

更新：重要一提的是，我不能僅僅依靠異常和自定義異常類型的錯誤報告，因爲一些客戶對這個應用程序將通過Web服務（SOAP & REST）

歡迎任何建議！

來源

2010-03-06 WayneC

我覺得這是更好地創建一個共同的項目（或項目ApplicationFramework），並把你的例外並在其上公共對象。

它始終是一個好主意有包含基類的類（特別是在UI - PageBase - MasterBase- ModuleBase和ETC）的ApplicationFramework

並作爲其明顯的，你必須把你的類並在您的BLL項目中枚舉。

請注意，3層並不意味着 3項目。你可以在BLL中有5個項目。

最後不要忘記使用ELMAH或任何其他類似的工具。

來源

2010-03-06 07:15:25

錯誤代碼是舊的skool，在COM和C編程的過去不好的日子裏，你需要它們，這些環境不支持異常。如今，您使用異常來通知客戶代碼或用戶有關問題。 .NET中的例外是自描述性的，它們具有類型，消息和診斷。

您需要區分兩種類型的異常，那些可合理恢復的異常和那些您不知道究竟發生了什麼問題或者如何從中恢復的異常。後一種是最常見的，你需要一個人來採取糾正措施。使用標準的內置.NET異常類型之一來提高它們。 IllegalOperationException，FormatException，ArgumentException是常見的選擇。如果是後端引發了這樣的異常，那麼你只是想在不改變的情況下通過它。你通常需要一個finally塊來確保你的內部狀態是一致的，有時候一個catch塊包含一個簡單的throw來恢復狀態。

任何您認爲可恢復的內容都應該使用您自己聲明的異常類型來引發，這些異常類型來自Exception類。這爲代碼上游提供了一個編寫catch子句並做一些有意義的事情的機會。您需要生成一個描述問題的消息，以防上游代碼實際上無法處理該消息，如果您需要從硬編碼字符串或資源中檢索消息文本支持本地化。

來源

2010-03-06 12:54:35

感謝您的意見。我已經更新了原始問題，提到我不能僅僅依賴異常，因爲有些客戶端將通過Web服務，特別是沒有「異常類型」概念的REST Web服務。看看一些互聯網API（Facebook，Flickr等），讓我相信這種使用方式中的錯誤代碼是最好的選擇。 – WayneC 2010-03-06 16:17:14

@WayneC：SOAP Web服務可以訪問SOAP Faults。太糟糕了，REST要求你恢復到90年代初。 – 2010-03-06 16:29:12

@John：你是說REST API是「90年代初」？有人更好地告訴Facebook，Flickr，Netflix，Twitter，Google等，他們應該與時俱進！ :-)即使採用異常方法，錯誤代碼對於進一步對異常進行分類仍然很有價值。例如，如果您有自定義的ValidationException，那麼您可以使用錯誤代碼來詳細說明失敗的驗證類型，而不是爲每個驗證方案創建新的自定義異常類型。 – WayneC 2010-03-06 22:56:11

.NET中的錯誤代碼/消息管理的方法

回答

相關問題