Why don't object reference error exceptions in .net tell me which object was null?

Question

Maybe asking the question betrays my lack of knowledge about the process, but then again, there's no better reason to ask!

Tracking these down can be frustrating because stack traces can help me know where to start looking but not which object was null.

What is going on under the hood here? Is it because the variable names aren't bundled in the executable?

Answer 1

.NET code built with full optimizations and no debug info: your local variable names are gone, some local variables may have been eliminated entirely.

.NET code built with full optimizations + PDB (or full debug): most local variable names preserved, some local variables may have been eliminated

No optimizations + no debug info: local variable names are gone.

And then we have to consider that whatever you're dealing with may not be in a local variable at all - it might have been the result of a previous function call, on which you're chaining a new function call.

Answer 2

Basically you answered your own question. When you're code is compiled it's transformed in intermediate language (IL). IL does not have variable names the way your code does, arguments to a method being called are pushed on to a stack before the method is called and the currents methods arguments and local variables are referred to by there position. I believe this is because this structure aids the JIT compiler generate code.

The pdb symbols file stores a mapping between the IL generated and your code. It is used to tell you which line in your code each method call in the call stack refers to. Possibly the information stored here isn't detailed enough to say which variable is null, or possibly it was just considered too expensive in terms when of perf to be able to do this. In any case, if you have allowed the compiler to optimize the IL generated there may no longer be a one to one mapping between the variables in the IL and the variables in your code.

Hope that helps, Rob