Common coding defect: Object reference not set to an instance of an object.

I see this in the ReSharper beta code from time to time.
We all cause this from time to time by coding things like

Foo foo = getFoo();
foo.Method();

where foo is null.
Suggestion to JetBrains:
Put preconditions on any method that expects non-null arguments.
Put guard statements around any usage that might be null.
This is basic good programming practice.
Of course I make the same mistake too often; I'm no better. We do that under pressure. I'm just encouraging the excellent programmers at JetBrains to hold each other to this high standard so I don't get this error anymore ]]>.
See http://www.eiffel.com "Design by Contract"
or
http://research.microsoft.com/specsharp/ "Non-null types"
Do you other programmers find yourself overlooking this too?
I can't wait till languages have a non-null type like SpecSharp is researching, to make it easier to avoid such errors at compile time.

1 comment
Comment actions Permalink

Hello David,

do I understand correctly that you propose to eliminate NullReferenceExceptions(NREs)
which now often
happen in ReSharper? If yes, we'd be happy to do that, and we're trying to
fix them ASAP :)

Regarding you references to programming languages support for static not-null
checking, we're of course
aware of these efforts. But none of them seem to be widely used yet (to the
best of my knowledge). It seems
for me that it's simply not feasible to "Put guard statements around any
usage that might be null", as there are many
thousands of such usages. Preconditions are useful, but we cannot annotate
all the external APIs we use. Additionally,
many NREs are implications of other internal problems (unexpected reentrancy
of a procedure is one example of those),
so static not-null checking doesn't help much with them. This is only my
opinion, of course. And it's really interesting what
do others think of this?

Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I see this in the ReSharper beta code from time to time. We all cause
this from time to time by coding things like

Foo foo = getFoo();
foo.Method();
where foo is null.

Suggestion to JetBrains:

Put preconditions on any method that expects non-null arguments.

Put guard statements around any usage that might be null.

This is basic good programming practice.

Of course I make the same mistake too often; I'm no better. We do that
under pressure. I'm just encouraging the excellent programmers at
JetBrains to hold each other to this high standard so I don't get this
error anymore <smile>.

See http://www.eiffel.com "Design by Contract"

or

http://research.microsoft.com/specsharp/ "Non-null types"

Do you other programmers find yourself overlooking this too?

I can't wait till languages have a non-null type like SpecSharp is
researching, to make it easier to avoid such errors at compile time.



0

Please sign in to leave a comment.