Obj reference not set...

[Marty McDonald]

The "object reference not set to an instance of an object" exception does
not give any info about the actual object reference that was null. Aside
from using more try/catch, is there some way to figure out which object
reference is causing the problem? Something descriptive, like in Debug
mode, but that is available in non-Debug mode? Is the IL that just executed
available? --Marty

[Marina]

Re: Obj reference not set...

No, you can't get anything more descriptive.

If you are in debug mode, you should have access to things like the line
number, etc, which narrows it down quite a bit. It's hard for the runtime
to give more information, as this is just related to the variable name,
which has no real meaning at runtime.

"Marty McDonald" <mcdonama@wsdot .wa.gov> wrote in message
news:%23$ohOjW2 DHA.556@TK2MSFT NGP11.phx.gbl.. .[color=blue]
> The "object reference not set to an instance of an object" exception does
> not give any info about the actual object reference that was null. Aside
> from using more try/catch, is there some way to figure out which object
> reference is causing the problem? Something descriptive, like in Debug
> mode, but that is available in non-Debug mode? Is the IL that just[/color]
executed[color=blue]
> available? --Marty
>
>[/color]

[Tian Min Huang]

RE: Obj reference not set...

Hello Marty,

Thanks for your post. As I understand, the problem you are facing is how to
figure out the problem which causes "object reference not set to an
instance of an object". Please correct me if there is any misunderstandin g.
I now share the following information with you:

Generally speaking, this error is caused when you declare a class variable
and use it without instantiating it. Such problem is easy to be identified
from the call stack when the exception throws. As you know, we are able to
dump the call stack in try/catch. Without try/catch code, you need to get
the symbole file (.pdb file) of the application, attach VS .NET debugger to
the process of it, and then we can view the call stack. Another method is
to use a tool say, ADPlus, to create a dump file when a process crashes,
open the dump file in a debugger say, windbg, to check the probolem.

In the meantime, I believe the following MSDN article is very helpful for
debugging .NET application:

Production Debugging for .NET Framework Applications
http://msdn.microsoft.com/library/de...us/dnbda/html/
DBGch01.asp

Please feel free to let me know if you have any problems or concerns.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Michael Giagnocavo [MVP]]

Re: Obj reference not set...

At non-debug mode, you should have worked these things out :).

Seriously, the way to do it is to add checks for objects that might be null.
If you have a method that takes an argument, and the arg should not be null,
check, and throw an ArgumentNullExc eption. If nulls are appearing
"randomly" throughout your code, see where the object is coming from.
Perhaps you're calling a method that returns a null on failure.

Splitting up expressions can help too, (for instance, doing:
myOBject.Param. SomeList[index].Property =
anotherList[index].SomeObject.Pro perty.ToString( ) has a lot of places that
could be null). Separating into multiple expressions can make it simpler to
find out where something's going wrong.

-mike
MVP

"Marty McDonald"
<mcdonama@wsdot .wa.gov> wrote in message
news:%23$ohOjW2 DHA.556@TK2MSFT NGP11.phx.gbl.. .[color=blue]
> The "object reference not set to an instance of an object" exception does
> not give any info about the actual object reference that was null. Aside
> from using more try/catch, is there some way to figure out which object
> reference is causing the problem? Something descriptive, like in Debug
> mode, but that is available in non-Debug mode? Is the IL that just[/color]
executed[color=blue]
> available? --Marty
>
>[/color]

[Marty McDonald]

Re: Obj reference not set...

OK - thanks everyone! I do know why these kinds of errors happen, and I
know how to try/catch them. My main point was that I was wondering if there
was any extra info available (such as via reflection) to help determine the
actual type of the null reference.

Your responses confirm that there really is no other way (besides good
coding practices, try/catch, checking args, etc) to avoid the error, and
there is no extra CLR information available about such exceptions.

Thank you for your information. --Marty