How can catched exception be null (not NullReferenceException)?

Question

I have run into a rather weird little problem.

In the following code I can not understand how e can be null;

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

As far as I know, throw null will be converted to throw new NullReferenceException().

The problem seems to be related to multithreading, as removing another thread also seems to fix it. Or at least I have only seen this when the above code is run in a new thread. The whole program uses many threads and is a bit complex.

Anyway my question is, how can e be null? - Hopefully the answer to that can help find the source of this problem.

Edit I discovered it since it caused a NullReferenceException in the catch statement, and using the debugger I see the same thing.

Edit 2 Open VisualStudio the next day tried again, no code changes and now the same catch phrase is "called" but this time e is not null. It appears it was a VS glitch.

Answer 1

How are you determining that e is in fact null? I've tried a few samples and read through the CLI spec on exceptions and it does not seem to allow for a exception value being null. Additionally if it was null, it would not have a type and hence wouldn't be able to meet the filter criteria for being of type exception.

Are you using the debugger to verify this value? If so, try switching it to an inline assert.

Answer 2

Are you positive you were off the Exception e line?

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

I only ask this because I have never, ever seen this kind of behaviour and I know that if you breakpoint Exception e, e seems to be null. On the next line it becomes not null.

Answer 3

It is possible that the exception being thrown is not CLS Compliant, which really shouldn't be catchable by a Try/Catch with a filter.

You should only be able to catch a CLS Compliant with a try {} catch {} with no exception "argument"

Answer 4

I have got the same situation, too. It happened to be a bug of Eclipse debugger. Eclipse restart is enough - runtime exception becomes normal, not null.