.NET – Why Object Reference Error Exceptions Don’t Specify Null Object?

.net-4.0debuggingnullreferenceexception

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?

Best Answer

.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.

Related Solutions

C# – Why NullReferenceException Lacks Null Information

An NRE is a very low-level exception. It is a hardware exception (a 'trap') generated by the processor when it is asked to read data from an address below 64K. That region of the virtual memory space is always unmapped, specifically to trap pointer bugs. It starts as an AccessViolation and gets turned into NRE by the CLR when the address is less than 0x00010000. At that point there is very little context for the exception, all that's known is the address of the machine code instruction that caused the trap.

Reverse-engineering that machine code instruction address back to a named variable in your program isn't possible. It is important that it works that way, a jitter would have to generate very inefficient code otherwise. All that can be reasonably done is recover the source code line number. That requires debugging info (a .pdb) that contains line number info. The CLR knows how to read the .pdb file and uses it to generate the exception's stack trace. However, this is often still inaccurate due to optimizations performed by the JIT optimizer, it moves code around. You'll only get a guaranteed match for the Debug build. The reason why the PDB for the Release build doesn't contain source line number info. You can change that.

This problem has a very simple solution. Check for null yourself and generate your own exception before letting the runtime do it. The test is quite cheap, well less than a nanosecond.

NullReferenceException – Why Variable Name is Not Provided in .NET

A NullReferenceException is thrown by the CLR when it tries to navigate a null reference. This isn't necessarily associated with a variable, and in particular the CLR really doesn't care where it came from - it's just a value on the stack.

Compare that with ArgumentNullException which is explicitly thrown via code such as:

if (foo == null)
{
    throw new ArgumentNullException("foo");
}

There's no magic here - and you can even give the wrong name if you want. So they're really very different situations.

Best Answer

Related Solutions

C# – Why NullReferenceException Lacks Null Information

NullReferenceException – Why Variable Name is Not Provided in .NET

Related Question