If an object is initialized to null, it is not possible to get the type information because the reference doesn’t point to anything.
However, when I debug and I hover over a variable, it shows the type information. Only the static methods are shown, but still, it seems to know the type. Even in release builds.
Does the debugger use other information than just reflection of some sort to find out the datatype? How come it knows more than I? And if it knows this, why isn’t it capable of showing the datatype in a NullReferenceException?
It seems like you’re confusing the type of the reference with the type of the value that it points to. The type of the reference is embedded into the DLL metadata and as readily accessible by the debugger. There is also aditional information stored in the associated PDB that the debugger leverages to provide a better experience. Hence even for null references a debugger can determine information like type and name.
As for
NullReferenceException. Could it also tell you the type on which it was querying a field / method … possibly. I’m not familiar with the internals of this part of the CLR but there doesn’t seem to be an inherent reason why it couldn’t do so.But I’m not sure the added cost to the CLR would be worth the benefit. I share the frustration about the lack of information for a null ref exception. But more than the type involved I want names! I don’t care that it was an
IComparable, i wanted to know it wasleftCustomer.Names are somethnig the CLR doesn’t always have access to as a good portion of them live in the PDB and not metadata. Hence it can’t provide them with great reliability (or speed)