4

Code:

items.FirstOrDefault(x => x.Foo.Bar.BarId == snuh.BarId);

Error:

System.NullReferenceException: Object reference not set to an instance of an object.

The null object could be items, Foo, Bar, or snuh.

The debugger/runtime can tell me on which line of code the error is occurring. Why can't it also tell me which object is the problem?

Note: I know I can debug this and find out the answer. Is there a reason Visual Studio can't provide me with the name of the offending object?

Bob Horn
  • 33,387
  • 34
  • 113
  • 219
  • I think it likely to be related to this post on Lampba expression and the fact you can not debug them:http://stackoverflow.com/questions/725499/vs-debugging-quick-watch-tool-and-lambda-expressions – Bit May 29 '14 at 14:43
  • 1
    Actually, x could also be null. Many collections let you add null as an item to the list. – Tony Vitabile May 29 '14 at 14:46
  • The null reference is detected by code that doesn't know what object generated the null reference. It's like saying that the sqrt function should say "cannot take square root of the negative number in the variable x" when you do sqrt(x) and x is negative. – Raymond Chen May 29 '14 at 18:36

3 Answers3

3

Because the debugger or the compiler have the source symbols, so they can map a name to an address.

The runtime, however, doesn't know how a reference was named in your source code (it has been compiled).

Note that you if you (not the CLR) throwed the NullReferenceException, then you could have added any information in the embedded message.

quantdev
  • 23,517
  • 5
  • 55
  • 88
  • +1 this answer because it mentions that if you were to throw the exception you could add your own information about which object is null through `try.. catch...` blocks as well as a good explanation. – Jfabs May 29 '14 at 14:48
  • But what about when I'm running in the debugger? Shouldn't the debugger be able to tell me? – Bob Horn May 29 '14 at 21:20
  • 1
    @BobHorn - the debugger is handed an exception and can determine the line that it originated from (if you're lucky). The only way it could determine which *part* of the line caused the exception would be to re-run each part and insert additional `NULL` checks - but that assumes that the line is deterministic and causes no side effects, and its safer for the debugger not to do that and play it safe. – Damien_The_Unbeliever May 30 '14 at 13:53
2

Due to optimizations, etc the relationship between "this reference stored in register R22/sitting in stack slot 5" and how that reference was actually obtained can be a difficult one to deduce.

All it knows, at this moment, is someone tried to dereference it and it turned out to be NULL.

And oftentimes, what it's trying to dereference may not have had a clear/understandable name in the source code either.

Damien_The_Unbeliever
  • 234,701
  • 27
  • 340
  • 448
0

It's pretty common with most languages to receive a null pointer but not specify the object. I'm pretty sure its because it can't find the object in the first place in order to tell you what it is.

Lex Webb
  • 2,772
  • 2
  • 21
  • 36