C＃處理異常和異常的數據錯誤和警告的最佳實踐

Question

我們正在創建一個新的.Net Core庫，這是一個駐留在Clean Architecture中的應用程序服務。

新服務將通過RepositoryService層讀取新的客戶詳細信息，並通過RestApiService層將其發布到多個系統，包括：CreditCheck系統，計費系統等。

在新的應用程序服務中，我們需要一種一致的方式來處理RestAPi服務的響應。 響應數據包括：

- Return values:  entities returned by restAPI service 

 - Exceptions like an error 500, time outs.. that have bubbled up from the RestAPi. 

- Data Errors messages such as Customer already exists, bank details invalid

- Warning messages ... "Processing continues as normal, but order is flagged" 

正是最后兩個使我們困惑，因為這不同於與沒有業務邏輯的與存儲庫層的交互，因此基本上返回成功或異常。

Microsoft和SOLID實際上聲明使用異常處理是必經之路，無論是異常，錯誤還是警告。

但是在這種情況下，不清楚如何工作..

  a. We loose the option of handling and forwarding on the return values. 
     We really don't fancy storing all this in the exception message

   - Whilst not a show stopper, we fear the code will be more difficult to read than it needs to be.    

   - Exception handling is expensive,but not worried too much on this score with number of transactions. 

我們被吸引了一些使用FluentValidation或混合版本的方式，它將需要與Logging和RepositoryService一起使用，因為我們需要記錄和解碼東西。

我們真的不希望重復RestAPi服務層方法，即分別處理HTTP異常，然后處理返回值，這些返回值基本上是帶有Errors Status，Error代碼和消息的擴展實體。

我們不希望上述內容特定於我們公司。 問題似乎與處理來自我們的應用程序服務中的第3方業務邏輯層的消息有關。

因此，我們的問題是，我們如何才能最好地處理應用程序服務層中附帶數據的錯誤警告，並且仍然具有可測試和可維護的SOLID代碼？

Answer 1

Microsoft和SOLID是正確的。

正確的方法是按照標准慣例（和c＃）進行異常處理，與其他考慮因素（例如性能）無關。

一般而言，有兩種不同類型的“錯誤”，即技術和業務邏輯。

無法連接到數據庫，無法從REST服務接收500，等等...都是技術性的，由於它們可能是暫時的，您可以嘗試從這種情況中恢復，有時沒有成功，最終導致業務編排/流程失敗。

業務邏輯錯誤（例如“客戶已存在”，“銀行明細無效”，“輸入數據不是有效格式”）是非暫時性的，並且僅由業務規則（某些隱式，其他顯式）確定，並且會停止停止您的操作僅僅因為某些事物未處於適當/預期的狀態而無法恢復。

我們之所以使用Exceptions（作為技術工件）是有原因的，並且要“適當”地處理這些困難。

每次拋出Exception時，應用程序都會遍歷堆棧，直到第一個可以處理此類Exception的可用Exception Handler為止，然后將控件返回給您，並返回到將要發生的已知位置（遙測，重新拋出，向用戶顯示對話框） ...）

任何試圖替代這種傳播（錯誤）的機制都必須依靠，例如劫持方法的返回值以提供狀態，或強制在所有方法簽名中包含out參數，這將對您產生嚴重的附帶影響實現。

是的，有時您當前的設計看起來“太平坦”，以至於您試圖在這里和那里劫持返回值，創建一個高度耦合的組件，但是您永遠無法知道系統復雜性將如何增長，這意味着您將在某個時候擴展您的系統需要額外的層，並且很可能無法采用“替代機制”方法，因此您不得不以常規方式和富於想象力的方式來支持它們。

因此，嘗試實施定制解決方案將產生緊密耦合的技術要求，必須全面支持它，從架構上來講，這根本就是“不好”（不好的做法）

如果您使用的任何服務都無法產生有意義的，結構合理的“錯誤”信息，則該服務的設計不正確，問題就會轉移到客戶端（使用SOA術語進行交流）。

唯一不會在您的客戶端中造成混亂的“最正確”解決方案是通過創建服務代理來尊重您實現方法所需的規則。

我對錯誤處理的建議非常簡單，請遵循眾所周知且已經存在數十年的規則，不要自己嘗試解決此問題，否則您將面臨太多問題，為每個服務創建一個代理，並且將它們正確集成到您的代碼庫中（單元測試等）

關於警告，沒有任何人建議通過使用異常來處理此問題，您的問題中的那些“警告”是與服務交互時的正常輸出/業務邏輯支持的邏輯狀態，因此是處理的地方此狀態再次出現在數據合同從服務返回的情況下，如果服務設計得如此糟糕，僅用包含“警告”一詞的文本字符串來答復您，並且您被迫解析該字符串以注意到情況，則您的服務代理應進行檢查，並向客戶提供有意義且結構合理的輸出。