Ninject - 如何在构造过程中识别哪个类抛出异常

Posted 2023-02-19

【中文标题】Ninject - 如何在构造过程中识别哪个类抛出异常

【英文标题】：Ninject - How to identify which class is throwing exception during construction

【发布时间】：2013-07-06 11:55:57

【问题描述】：

我们正在使用 Ninject 3.0 来解析一个类。 相当无聊的标准东西：

IKernel kernel = GetKernel(); 
var foo = kernel.Get<IFoo>(); 

但是，在一台特定的机器上，我们在构造... something 时遇到了异常。我们知道发生了什么，但它在日志框架 (Common.Logging) 中，并且该代码在我们的代码库中使用，在所有/大多数构造函数中。

除了将每个构造函数放在 try/catch 中并使用类型信息包装异常之外，我没有从 Ninject 那里得到任何有用的信息来说明它遇到了什么问题。

有什么方法可以让 Ninject 告诉我们它未能创建哪个类？

Another person asks a similar question，但他们的解决方案没有帮助 - 我们从日志框架而不是 Ninject 获取异常。

【问题讨论】：

请向我们展示堆栈跟踪，包括内部异常的堆栈跟踪。此信息应包含初始化失败的类的构造函数。

初始化失败的类正是我想让 Ninject 告诉我的。它不给那个类。

对我来说听起来像是 Ninject 中的一个错误。 Ninject 应该包装抛出的异常。您应该将此作为错误报告给 Ninject 团队。

@Steven 我刚刚验证了 Ninject 不会吞下任何异常。有一个例外：当您调用 TryGet 时，它将吞下该异常，因为如果该方法无法解析实例，则该方法必须返回 null。如果异常被吞下，那么它一定是在应用程序/日志框架代码中的某个地方。否则调用 Get 时应该会出现异常。

威尔，您可能想尝试注册AppDomain.FirstChangeException 事件以找出引发此异常的位置。

【参考方案1】：

这并不是真正的解决方案，但是当我遇到问题时，我会一次手动删除一个构造函数依赖项，直到找到问题依赖项。当我验证没有那个依赖的所有工作时，我就会进入那个具体的实现。我本质上是递归的，从入口点向下遍历每个依赖项，删除每个依赖项，直到识别出未绑定的依赖项。很累，但蛮力还没有让我失望。即使当我遇到一个私有构造函数是导致问题的原因时，如果没有蛮力，我也永远不会得到它。但更常见的是，它是某处的未绑定类型或条件注入。

【讨论】：

是的，不幸的是，有时这会发生在非常大的系统中 - 依赖项的数量可能达到数百甚至数千。