我想知道，有没有可能要求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