I'm guessing that NullReferenceExceptions are by far the most common exceptions thrown in .net.

Why not add the type of the reference to the message? Have it say something like:
Object reference of type 'string' not set to an instance of an object.

This would really help when trying to figure out where the null reference is happening.

I've just spent the last two days finding a null reference that happens very intermittently. Having the type would have saved me many hours.

In addition to just the type, you might be able to use reflection to give a property name or variable name.

Bryan Livingston

Please tell me you have exceptions set to 'break' in the debugger.... if you
do, it's usually absolutely obvious what the null reference should have
been.

[quoted text, click to view]

And if not Bryan, then don't worry - you know to now :-)

[quoted text, click to view]

Cheeky... they're off by default which seems odd to me.
The options are under Debug -> Exceptions, and I usually have all set to
break (with a few exceptions).
I think the exception already does have the stack trace in it, so even if
you're not running under the debugger you could log the stack trace of an
exception which reaches a certain level.



[quoted text, click to view]

The exception only happens on a production website and only occours about once every three days. I havn't been able to reproduce it in a debug environment.

Since we are doing financial transactions on the site I don't exactly have time to dick around with attaching a debugger. I have to get the site back up right away.

Bryan

----- Stu Smith wrote: -----

Please tell me you have exceptions set to 'break' in the debugger.... if you
do, it's usually absolutely obvious what the null reference should have
been.

[quoted text, click to view]

For the record, here is what one of the program managers for the CLR had to say about it

The NullReferenceException occurs because an instruction like “call [eax+44]” or “mov edx, [esi+24]” has resulted in an access violation. We don’t retain nearly enough information to form a correspondence between a particular register being NULL at a particular EIP and the fact that a particular reference in the application was null. Especially since the EIP might be in a shared helper like a write barrier routine or an array helper. In those cases, we would have to perform a limited stack walk to get the effective EIP



The machinery that would be required to improve this error message is huge. For the foreseeable future, you will have to rely on debuggers, or on FX code explicitly checking and throwing an appropriate NullArgumentException

Chris.
http://blogs.msdn.com/cbrumme


----- Bryan Livingston wrote: ----

I'm guessing that NullReferenceExceptions are by far the most common exceptions thrown in .net

Why not add the type of the reference to the message? Have it say something like
Object reference of type 'string' not set to an instance of an object

This would really help when trying to figure out where the null reference is happening

I've just spent the last two days finding a null reference that happens very intermittently. Having the type would have saved me many hours

In addition to just the type, you might be able to use reflection to give a property name or variable name

Bryan Livingsto

Thanks for your suggestion. I will add this to our list for future
considerations.

Once suggestion is create a trace/log system where you can log activities
on the web site to help debug the problem.

Thanks,
Kelvin

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
[quoted text, click to view]
to say about it:

The NullReferenceException occurs because an instruction like “call
[eax+44]” or “mov edx, [esi+24]” has resulted in an access violation.
We don’t retain nearly enough information to form a correspondence
between a particular register being NULL at a particular EIP and the fact
that a particular reference in the application was null. Especially since
the EIP might be in a shared helper like a write barrier routine or an
array helper. In those cases, we would have to perform a limited stack
walk to get the effective EIP.



The machinery that would be required to improve this error message is huge.
For the foreseeable future, you will have to rely on debuggers, or on FX
code explicitly checking and throwing an appropriate NullArgumentException.

Chris.
http://blogs.msdn.com/cbrumme


----- Bryan Livingston wrote: -----

I'm guessing that NullReferenceExceptions are by far the most common
exceptions thrown in .net.

Why not add the type of the reference to the message? Have it say
something like:
Object reference of type 'string' not set to an instance of an object.

This would really help when trying to figure out where the null
reference is happening.

I've just spent the last two days finding a null reference that
happens very intermittently. Having the type would have saved me many
hours.

In addition to just the type, you might be able to use reflection to
give a property name or variable name.

Bryan Livingston
Alphora.com
[quoted text, click to view]