5

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.

Jacob Poul Richardt
  • 3,145
  • 1
  • 26
  • 29

4 Answers4

7

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.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • I'll update the question with this. But it caught my attention because a NullReferenceException was thrown from the catch statement. And using the debugger I see the same thing. – Jacob Poul Richardt Dec 03 '09 at 18:07
  • 3
    @Lillemanden, this doesn't prove it's null though. Only a Debug.Assert(e != null, "It's definitely null") or a similar check will do this. – JaredPar Dec 03 '09 at 18:31
  • 2
    Debugger sometimes lies. I remember there is something entertaining with constants and the debugger where they appear to be empty or null when they are not in reality. – Quibblesome Dec 03 '09 at 19:03
  • I wanted to do the test again today, but now e is no longer null. So no the error handling is working like it should. It appears it was some kind of freak VisualStudio glitch. I'll give you the credit since it is related to the debugger. – Jacob Poul Richardt Dec 04 '09 at 15:02
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.

Quibblesome
  • 25,225
  • 10
  • 61
  • 100
1

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"

Brett Allen
  • 5,297
  • 5
  • 32
  • 62
  • I am fairly sure all the code is CLS compliant. Though not 100%. But I have never had this problem before. And there are plenty other such catch statements, most of which should have been tested by unit tests. – Jacob Poul Richardt Dec 03 '09 at 19:11
0

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.

Gangnus
  • 24,044
  • 16
  • 90
  • 149