15

"Object reference not set to an instance of an object"

Why does the exception not also show the name of the object reference field, or at least its type?

This is probably one of the most common run-time errors in .NET. Although the System.Exception has a stack trace, there are no other helpful details.

Over the course of a year I spend hours sifting through stack traces (often in code I did not write), hoping there is a line number from a ".pdb" file, then finding the line in the code, and even then it is often not obvious which reference on the line was null. Having the name of the reference field would be very convenient.

If System.ArgumentNullException instances can show the name of the method parameter ("Value cannot be null. Parameter name: value"), then surely System.NullReferenceException instances could include the name of the null field (or its containing collection).

Simon Chadwick
  • 1,148
  • 6
  • 12

4 Answers4

6

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.

Igor Zevaka
  • 74,528
  • 26
  • 112
  • 128
  • It is not true that the variable names disappear in IL. Run ILDasm or Reflector on an assembly and see. – Simon Chadwick May 27 '10 at 03:09
  • 1
    Thanks for your updated answer and its insights - you make a very good point about the complex sources of some NullReferenceExceptions (my +1). Still it seems that for simple null field reference exceptions, even without an external API, the .NET runtime could provide more details. In your more complex example, there is still not enough evidence as to exactly why the runtime could not explicitly identify either "myObject", "myObject.GetOtherObject() return value", or "myObject.GetOtherObject().ThirdObject" as the NullReferenceException sources. If it takes a parse tree, then so be it! – Simon Chadwick May 27 '10 at 05:48
2

This has been covered here: Detecting what the target object is when NullReferenceException is thrown

and here: Why can't 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.

Community
  • 1
  • 1
Sam Saffron
  • 128,308
  • 78
  • 326
  • 506
  • Thanks for the (first) link. That question deals more with the target object (or lack of one), and how to debug the problem. You may be correct about the expensive processing in determining the source of the NRE, but especially for Debug builds, this would be insignificant compared to the debugging effort involved. – Simon Chadwick May 27 '10 at 02:48
1

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.

Joe
  • 122,218
  • 32
  • 205
  • 338
  • +1 for an interesting point for further study. Without knowing much about PDB files and how they are used at runtime, the line and column numbers where faults occur are linked somehow to the JITed code, so perhaps other information could be as well, especially for Debug builds. – Simon Chadwick May 27 '10 at 18:03
-1

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.

Sameh Deabes
  • 2,960
  • 25
  • 30
  • Thanks, but I know how to debug in VS; that is not the point. I want to know why .NET cannot be more explicit with NullReferenceExceptions. Often I would not even have to debug code if I knew the name of the unset field. – Simon Chadwick May 27 '10 at 03:06