抓.NET的例外是意外空 [英] .NET exception caught is unexpectedly null

查看:111
本文介绍了抓.NET的例外是意外空的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

请参阅以下哪些是在

我有一个很奇怪的问题,即捕捉到的异常为null。

I have a really weird issue where the exception caught is null.

中的代码使用MEF,并力图组成报告错误。使用调试器,我可以看到异常被抛出(在出现InvalidOperationException ),但是,当它是由最后一个catch块下面的前<代码捕获/ code>变量为空。这是真正的无论是在调试器和正常执行代码时

The code uses MEF and tries hard to report composition errors. Using the debugger I can see the exception being thrown (an InvalidOperationException) but when it is caught by the last catch block in the code below the ex variable is null. This is true both in the debugger and when executing the code normally.

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;
}



我与评论替代的代码是非常简单的代码格式错误信息。 。没有什么奇怪的事情出现。

The code I have replaced with comments is really simple code to format the error message. Nothing strange going on there.

我试图修改代码以发现可能有什么样的影响:

I have tried to alter the code to discover what effect that might have:


  • 如果我删除第一个catch块( ReflectionTypeLoadException )夹在决赛catch块异常不再为空。

  • 如果我赶上了第一个catch另一个异常类型的块夹在最后的catch块异常不再为空。

  • 如果我添加一个catch块出现InvalidOperationException 作为第一个catch块捕获该块中的例外,不为null。

  • 如果我添加一个catch块出现InvalidOperationException 这两个catch块的夹缝该块中的例外是空。

  • If I remove the first catch block (ReflectionTypeLoadException) the exception caught in the final catch block is no longer null.
  • If I catch another exception type in the first catch block the exception caught in the final catch block is no longer null.
  • If I add a catch block for InvalidOperationException as the first catch block the exception caught in that block is not null.
  • If I add a catch block for InvalidOperationException between the two catch blocks the exception caught in that block is null.

该项目采用<一个HREF =http://research.microsoft.com/en-us/projects/contracts/>代码契约以及由编译器生成的代码是后处理,以检查合同。不幸的是,我没有带想出一个办法来获得用于测试目的摆脱这种没有对项目进行大手术。

The project uses Code Contracts and the code generated by the compiler is post-processed to check the contracts. Unfortunately, I havn't figured out a way to get rid of this for testing purposes without performing major surgery on the project.

我目前的解决方法是不赶 ReflectionTypeLoadException 在一般的异常处理程序的类型,而不是分支。

My current workaround is to not catch ReflectionTypeLoadException and instead branch on the type of ex in the general exception handler.

有什么能为这个不可能的行为的解释?什么是与 ReflectionTypeLoadException catch块?

What could be the explanation for this "impossible" behavior? What is up with ReflectionTypeLoadException catch block?

尴尬异常不为空,也不能每C#的标准15.9.5空

Embarrassingly the exception is not null and it cannot be null per the C# standard 15.9.5.

不过,使用代码契约在项目的可以搞砸局部变量在调试显示,因为编译器生成的IL代码可以通过代码契约改写所以最终的IL稍微不与调试信息同步。在我的情况下变量显示为空,即使它不是。错误报告发生的权利之前应用程序终止的意思,我认为错误报告不被称为被空和 ex.Message 投掷的NullReferenceException 我的catch块中。使用调试器,我能够为验证了为空,但它实际上是不为空。

However, using Code Contracts in a project can mess up the display of local variables in the debugger because the IL code generated by the compiler can be rewritten by Code Contracts so the final IL is slightly out of sync with the debug information. In my case the ex variable is displayed as null even it is not. The unfortunate nature of the error reporting taking place right before application termination meant that I believed the error reporting to not be called as a result of ex being null and ex.Message throwing a NullReferenceException inside my catch block. Using the debugger I was able to "verify" that ex was null, except it was actually not null.

我的困惑是由事实复杂化,对于一个catch块 ReflectionTypeLoadException 似乎影响调试器显示问题。

My confusion was compounded by the fact that a catch block for ReflectionTypeLoadException seems to affect the debugger display issue.

谢谢所有谁回答。

推荐答案

恰好碰到了同样的问题。我终于发现,我逮住不同的异常具有相同的名称,像你这样:

Just ran into this same problem. I finally found out that I catched different exceptions with the same name, like you did:

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



这两个被命名为恩。同时更改名称之一解决了这个问题对我来说,这样的:

Both are named 'ex'. Changing one of both names solved this problem for me, like:

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

这篇关于抓.NET的例外是意外空的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆