捕获的.NET异常意外为null

如何解决捕获的.NET异常意外为null

| 请参阅下文，了解发生的情况 我有一个非常奇怪的问题，其中捕获的异常为null。 该代码使用MEF，并尝试报告组合错误。使用调试器，我可以看到抛出了异常（“ 0”），但是当变量“ 1”下方的代码中的最后一个catch块捕获了该异常时，则为null。在调试器中和正常执行代码时都是如此。

static T ResolveWithErrorHandling<T>() where T : class
{
    try
    {
        IocContainer.Compose(Settings.Default.IocConfiguration);
        return IocContainer.Resolve<T>();
    }
    catch (ReflectionTypeLoadException ex)
    {
        // ... special error reporting for ReflectionTypeLoadException
    }
    catch (Exception ex)
    {
        // ex is null - that should not be possible!
        // ... general error reporting for other exception types
    }
    return null;
}

我用注释替换的代码实际上是格式化错误消息的简单代码。那里没什么奇怪的。 我试图更改代码以发现可能产生的影响： 如果删除第一个catch块（

ReflectionTypeLoadException

），则在最后一个catch块中捕获的异常不再为null。 如果我在第一个catch块中捕获了另一个异常类型，则在最后一个catch块中捕获的异常不再为null。 如果我为第一个catch块添加一个ѭ0的catch块，则该块中捕获的异常不为null。 如果在两个catch块之间添加一个ѭ0的catch块，则该块中捕获的异常为null。 该项目使用代码合同，并且对编译器生成的代码进行后处理以检查合同。不幸的是，我没有找到一种方法可以在不对项目进行大手术的情况下将其用于测试目的。 我当前的解决方法是不捕获

ReflectionTypeLoadException

，而是在常规异常处理程序中跳转到

ex

类型。 这种“不可能”行为的解释可能是什么？

ReflectionTypeLoadException

挡块怎么了？ 令人尴尬的是，异常不是null，并且按照C＃标准15.9.5不能为null。 但是，在项目中使用代码协定可能会使调试器中的局部变量显示混乱，因为由代码协定可以重写编译器生成的IL代码，因此最终的IL与调试信息略有不同步。在我的情况下，“ 1”变量显示为null，即使不是。错误报告的不幸性质是在应用程序终止之前发生的，这意味着我相信由于

ex

为空并且

ex.Message

在catch块内抛出

NullReferenceException

，因此不会调用该错误报告。使用调试器，我可以\“验证\”

ex

为空，但实际上并非为空。 ѭ3fusion的catch块似乎影响调试器显示问题，使我的困惑更加复杂。 感谢所有回应。     

解决方法

只是遇到了同样的问题。我终于发现，我像您一样捕获了同名的不同异常：

catch (ReflectionTypeLoadException ex)
{
    // ... 
}
catch (Exception ex)
{
    // ex is not null!
    // ...
}

两者都被命名为\'ex \'。更改两个名称之一对我来说解决了这个问题，例如：

catch (ReflectionTypeLoadException reflectionEx)
{
    // ... 
}
catch (Exception ex)
{
    // ex is null - that should not be possible!
    // ...
}

    ,我遇到了同样的问题。在我的情况下，重命名异常变量（例如ex => ex1）允许我捕获任何异常...     ,您应该检查IocContainer是否在某个时候捕获到

Exception ex

抛出

ex.InnerException

，而不检查它是否为null。 C＃高兴地接受

throw null

，最后以

catch (Exception)

结束。     ,我遇到了同样的问题。即使在正确的异常类型UpdateException中被捕获，在调试器中查看时，该异常还是null。我可以通过打开“异常助手”来查看异常。 一旦我关闭“执行运行时合同检查”，就会发现不再为null的异常。我一直在积极地使用代码合同，现在已经一年了，最近在这个特定项目中开始使用EF 4.1之前，还没有遇到这个问题-但是我不知道EF是否是捕获异常为零的控制变量。 。     ,实际上不是异常，这是调试器的问题。 代码协定（ccrewrite）会更改IL操作码，这会扰乱调试器，因为Leave.s操作码已转换为离开操作码。 这两个操作码的大小不同，指令地址也有所变化，这就是为什么当异常名称相同时调试器会丢失的原因。 您可以在调试器中使用$ exception来解决此问题。     ,我也有同样的情况。碰巧是Eclipse调试器的错误。 （确实，这种情况只能是某些调试器的错误导致的。） Eclipse重新启动就足够了-运行时异常变为正常，而不是null。其他调试器可能不是那样。