"Object reference not set to an instance of an object": why can't .NET show more details?

Answer 1

This has been covered here: http://stackoverflow.com/questions/115573/detecting-what-the-target-object-is-when-nullreferenceexception-is-thrown

and here: http://stackoverflow.com/questions/578734/why-cant-a-null-reference-exception-name-the-object-that-has-a-null-reference

The reason is mainly cause the runtime has no idea when the NRE is encountered. My guess it that it would have to work back the callstack and through the parse tree, which would be really expensive.

Answer 2

I did not find this exception that hard to deal with!

If I know the line number. I just insert a breakpoint at this line, run the application to this line, and when the debugger stops, I hover every variable/object in the line, and thanks to Visual Studio, it shows me their values.

Also I found Autos window very helpful in such cases, but the procedure I described above solves my problem quickly.

Answer 3

The difference between ArgumentNullException and NullReferenceException is that ArgumentNullException is always thrown explicitly like so:

if (parameter == null)
  throw new ArgumentNullException("parameter");

Had a quick look at ILDASM output, the local variables are indeed present inside a function's IL. There is still, however, no API to retrieve those names programatically. My understanding is that it would be fairly complex as you would basically need to build a parse tree that represents a function with scopes, variables, statements etc.

It's further complicated by the fact that it's not just simple variables that can throw NullReferenceException, but result of a function call, a property or an expression. I could get pretty complicated pretty fast.

Imagine this:

internalObject.OtherProperty = myObject.GetOtherObject().ThirdObject.SomeProperty == "value"
 ? myObject.OtherProperty
 : myObject.GetSomethingElse();

There are multiple points of failure there and building up a string representing what is actually null could be tricky.

Answer 4

Even though the variable name and type may exist in the MSIL code, it won't exist in the native code when the MSIL is JITted.

It would be incredibly inefficient to add this kind of check to the native code during JITting - essentially an overhead whenever a pointer is dereferenced.