我想知道，有沒有可能要求Unity「不要在解決時間包裝任何用戶異常」？Unity對ResolutionFailedException的異常進行包裝。如何避免？
真的，爲什麼Unity會對ResolutionFailedException進行封裝？它正在改變「建設服務合同」，恕我直言，使用統一對象初始化的事實應該是透明的，這意味着如果客戶端等待來自「新」運算符的IOException異常，它應該解開它，甚至使用Unity創建對象。
其他IoC容器的行爲是否相同？
因爲你的constructors should contain no logic。
我知道這不是一個完全令人滿意的答案，但我不知道，你可以關掉在Unity這種行爲 - 我也做同意，這是一個奇怪的設計決定...
然而，如果你保持你的構造器簡單，你就不會有這個問題。
結賬ResolutionFailedException.InnerException。
它正改變着 「建設服務合同」
什麼合同？
恕我直言對象初始化使用統一的事實應該是透明的
IoC容器的一個點是使重點建設對象較少，因此開發人員可以集中精力提高業務價值。
這意味着如果客戶端等待來自「new」運算符的IOException異常，它應該解開它，甚至使用Unity創建對象。
哇，客戶正在使用的容器，預計IOException？我認爲你可能會濫用你的IoC容器。
我想繼續爲我的客戶端使用Unity透明。 –
「IoC容器的一點..商業價值..」我在詢問具體的Unity功能。對不起，我討厭所有這些「商業價值」洗腦。 –
@Roman Pokrovskij：不，這裏沒有商業價值洗腦。你做了一個陳述;我不同意。你的陳述是使用Unity的對象構造應該是透明的。 IoC容器的重點在於爲您（除其他之外）爲您構建對象構建。我們使用IoC容器爲我們處理對象構建的原因是因爲花費時間解決不會爲我們的利益相關者增加價值是一個無聊的問題。 – jason
Unity包裝異常的原因全是關於合同 - 解決方法的合同。
當Resolve拋出時應該捕獲什麼？假設你確實解決了一個你知道拋出IOException的類。所以你在這個解決方案調用中爲這個異常做了一個捕獲。
然後執行改變。或者只是配置。現在這些服務會拋出別的東西。
現在您已經進行了需要更改代碼的配置更改。不好。
第二個原因是，在包裝異常情況下，容器有一個地方可以提供有關解決過程中發生故障的位置的診斷信息。
我也有類似的需求，並在這裏找到了一個解決方案：catch all unhandled exceptions in ASP.NET Web Api
這裏是我所學到的審查從鏈接的文章的答案時：
構造函數不應該包含任何邏輯，但是它們的確有很多情況。 ：/ –
假設我們只有在整個實例生命中應該被調用的方法，這個函數/測試必須在使用其他方法（如自定義身份驗證的東西）之前完成。很自然地把這個測試放到構造函數中。還有其他變體（首先生成代理，並與「GetIntance」一起執行身份驗證;或者在每次調用時測試isAuthenticated標誌，如果爲false，則執行身份驗證並設置爲true），但我不能分享這些算法更好的意見。謝謝你的文章。 –
@Roman Pokrovksij：做這件事很自然，但這並不正確。這個責任應該在其他地方委託，而不是在對象構造函數中。 – jason