捕获的异常如何为空（不是 NullReferenceException）？答案

【问题标题】：How can catched exception be null (not NullReferenceException)?捕获的异常如何为空（不是 NullReferenceException）？
【发布时间】：2010-12-22 22:13:57
【问题描述】：

我遇到了一个相当奇怪的小问题。

在下面的代码中我无法理解e 怎么可能是null;

try
{
    //Some Code here
}
catch (Exception e)
{
    //Here e is null
}

据我所知，throw null 将被转换为throw new NullReferenceException()。

这个问题似乎与多线程有关，因为删除另一个线程似乎也可以解决它。或者至少我只在上面的代码在新线程中运行时看到了这一点。整个程序使用了很多线程，有点复杂。

无论如何我的问题是，e 怎么可能是空的？ - 希望这个问题的答案可以帮助找到这个问题的根源。

编辑我发现它是因为它在 catch 语句中导致了 NullReferenceException，并且使用调试器我看到了同样的情况。

编辑 2 第二天打开 VisualStudio 再次尝试，没有代码更改，现在相同的流行语是“调用”，但这次 e 不为空。看来这是一个 VS 故障。

【问题讨论】：

听起来好像您已经开始解决问题了。你需要把胎面弄直。

标签： c# .net multithreading exception exception-handling

【解决方案1】：

您如何确定 e 实际上为空？我尝试了一些示例并通读了有关异常的 CLI 规范，但它似乎不允许异常值为 null。此外，如果它为 null，则它没有类型，因此无法满足过滤条件为异常类型。

您是否使用调试器来验证此值？如果是这样，请尝试将其切换为内联断言。

【讨论】：

我会用这个更新问题。但它引起了我的注意，因为从 catch 语句中抛出了 NullReferenceException。并且使用调试器我看到了同样的事情。
@Lillemanden，但这并不能证明它是空的。只有 Debug.Assert(e != null, "It's absolute null") 或类似的检查才能做到这一点。
调试器有时会撒谎。我记得常量和调试器有一些有趣的地方，当它们不在现实中时，它们看起来是空的或空的。
我今天想再做一次测试，但现在 e 不再为空。所以没有错误处理像它应该的那样工作。看来这是某种怪异的 VisualStudio 故障。我会给你功劳，因为它与调试器有关。

【解决方案2】：

您是否肯定您已脱离了异常 e 行？

try
{
    //Some Code here
}
catch (Exception e)
{
    int i = 0; // breakpoint here
}

我之所以这么问，是因为我从来没有见过这种行为，而且我知道如果你断点异常 e，e 似乎是空的。在下一行，它变得不为空。

【讨论】：

是的，我很肯定。在 catch 语句中使用 e 会导致 NullReferenceException 出现。

【解决方案3】：

抛出的异常可能不符合 CLS，它实际上不应该被带有过滤器的 Try/Catch 捕获。

您应该只能使用 try {} catch {} 捕获符合 CLS 的规则，没有异常“参数”

【讨论】：

我很确定所有代码都符合 CLS。虽然不是100%。但我以前从未遇到过这个问题。还有很多其他这样的 catch 语句，其中大部分都应该经过单元测试的测试。

【解决方案4】：

我也遇到了同样的情况。它恰好是 Eclipse 调试器的一个错误。 Eclipse重启就够了——运行时异常变正常，不为空。

【讨论】：