Multiple levels of Null Checking

[Karch]

I find myself doing things like this all the time:

if (
SomeObject != null &&
SomeObject.Anot herObject != null &&
SomeObject.Anot herObject.YetAn other != null &&
SomeObject.Anot herObject.YetAn other.HelpMePle ase != null)
{
// Do Something
}

Surely there must be a better way that I am missing? I thought about the
using statement, but that of course depends upon the IDisposable interface
being implemented, right?

Thanks!

[Jon Skeet [C# MVP]]

Re: Multiple levels of Null Checking

Karch <nospam@absotut ely.comwrote:

I find myself doing things like this all the time:
>
if (
SomeObject != null &&
SomeObject.Anot herObject != null &&
SomeObject.Anot herObject.YetAn other != null &&
SomeObject.Anot herObject.YetAn other.HelpMePle ase != null)
{
// Do Something
}
>
Surely there must be a better way that I am missing? I thought about the
using statement, but that of course depends upon the IDisposable interface
being implemented, right?

That suggests that each of those properties can legitimately be null -
is that always the case? I usually find that most of my properties
should always be non-null, in which case I'm happy for a
NullReferenceEx ception to be thrown if I try to dereference it and it's
null.

Code like the above happens occasionally, but not *that* often. As
another point, I rarely end up using properties 4 levels deep - I
usually try to design classes so that I can ask one class to do what
I'm interested in, without going through several levels.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Rad]

Re: Multiple levels of Null Checking

On Tue, 14 Nov 2006 13:19:07 -0600, "Karch" <nospam@absotut ely.com>
wrote:

>I find myself doing things like this all the time:
>
>if (
>SomeObject != null &&
>SomeObject.Ano therObject != null &&
>SomeObject.Ano therObject.YetA nother != null &&
>SomeObject.Ano therObject.YetA nother.HelpMePl ease != null)
>{
// Do Something
>}
>
>Surely there must be a better way that I am missing? I thought about the
>using statement, but that of course depends upon the IDisposable interface
>being implemented, right?
>
>Thanks!
>

Not sure if I understand you .. if AnotherObject is a property of
SomeObject, and SomeObject is null, I believe AnotherObject should
also be null

[Tom Porterfield]

Re: Multiple levels of Null Checking

Rad wrote:

On Tue, 14 Nov 2006 13:19:07 -0600, "Karch" <nospam@absotut ely.com>
wrote:
>

>I find myself doing things like this all the time:
>>
>if (
>SomeObject != null &&
>SomeObject.Ano therObject != null &&
>SomeObject.Ano therObject.YetA nother != null &&
>SomeObject.Ano therObject.YetA nother.HelpMePl ease != null)
>{
> // Do Something
>}
>>
>Surely there must be a better way that I am missing? I thought about the
>using statement, but that of course depends upon the IDisposable
>interface being implemented, right?
>>
>Thanks!
>>

>
Not sure if I understand you .. if AnotherObject is a property of
SomeObject, and SomeObject is null, I believe AnotherObject should
also be null

Yes, but SomeObject could be not null yet SomeObject.Anot herObject is null.
That is the order that he is checking.
--
Tom Porterfield

[Jon Skeet [C# MVP]]

Re: Multiple levels of Null Checking

Rad <nospam@nospam. comwrote:

On Tue, 14 Nov 2006 13:19:07 -0600, "Karch" <nospam@absotut ely.com>
wrote:
>

I find myself doing things like this all the time:

if (
SomeObject != null &&
SomeObject.Anot herObject != null &&
SomeObject.Anot herObject.YetAn other != null &&
SomeObject.Anot herObject.YetAn other.HelpMePle ase != null)
{
// Do Something
}

Surely there must be a better way that I am missing? I thought about the
using statement, but that of course depends upon the IDisposable interface
being implemented, right?

>
Not sure if I understand you .. if AnotherObject is a property of
SomeObject, and SomeObject is null, I believe AnotherObject should
also be null

If SomeObject is null, then trying to evaluate SomeObject.Anot herObject
will throw a NullReferenceEx ception, which is what the OP is presumably
trying to avoid.

Shameless plug - you could do it in Groovy:
if (SomeObject?.An otherObject?.Ye tAnother?.HelpM ePlease != null)
{
....
}

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Tom Porterfield]

Re: Multiple levels of Null Checking

Jon Skeet [C# MVP] wrote:

>
Shameless plug - you could do it in Groovy:
if (SomeObject?.An otherObject?.Ye tAnother?.HelpM ePlease != null)
{
....
}

groooooovy.
--
Tom Porterfield

[Karch]

Re: Multiple levels of Null Checking

Yes, they could legitimately be null - I am talking about classes here. One
good example is ADO.NET where you have multiple levels of checking that
needs to happen. Of course, in the below example, I am trying to use the
last level (HelpMePlease instance), but I need to make sure that all those
levels above it are non-null first, otherwise I get the null exception.

Perhaps I expect that some of these could be null a significant number of
times during execution. It seems to be a sort of hack to just wrap the whole
thing in a try-catch and then continue on. After all, I would like to
reserve exceptions for those cases when something unexpected occured and I
can take remedial actions.

"Jon Skeet [C# MVP]" <skeet@pobox.co mwrote in message
news:MPG.1fc42c 3aedf18c9698d60 2@msnews.micros oft.com...

Karch <nospam@absotut ely.comwrote:

>I find myself doing things like this all the time:
>>
>if (
>SomeObject != null &&
>SomeObject.Ano therObject != null &&
>SomeObject.Ano therObject.YetA nother != null &&
>SomeObject.Ano therObject.YetA nother.HelpMePl ease != null)
>{
> // Do Something
>}
>>
>Surely there must be a better way that I am missing? I thought about the
>using statement, but that of course depends upon the IDisposable
>interface
>being implemented, right?

>
That suggests that each of those properties can legitimately be null -
is that always the case? I usually find that most of my properties
should always be non-null, in which case I'm happy for a
NullReferenceEx ception to be thrown if I try to dereference it and it's
null.
>
Code like the above happens occasionally, but not *that* often. As
another point, I rarely end up using properties 4 levels deep - I
usually try to design classes so that I can ask one class to do what
I'm interested in, without going through several levels.
>
--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Rad]

Re: Multiple levels of Null Checking

On Tue, 14 Nov 2006 14:47:42 -0500, "Tom Porterfield"
<tpporter@mvps. orgwrote:

>>
>Not sure if I understand you .. if AnotherObject is a property of
>SomeObject, and SomeObject is null, I believe AnotherObject should
>also be null

>
>Yes, but SomeObject could be not null yet SomeObject.Anot herObject is null.
>That is the order that he is checking.

My mistake ... I seem to have read he was checking FOR null.

Whoops

[Jon Skeet [C# MVP]]

Re: Multiple levels of Null Checking

Karch <nospam@absotut ely.comwrote:

Yes, they could legitimately be null - I am talking about classes here.

Just because they're classes doesn't mean they can legitimately be
null. I often have classes where the properties are guaranteed not to
be null - if anything is null it indicates there's an error in my code.
(Not all properties work that way, but many do.)

A good example of this might be
StreamWriter.En coding.BodyName .Length - if any of the properties in
that path ended up being null, I'd be very concerned, despite them all
being classes (until the final property returning an int).

One good example is ADO.NET where you have multiple levels of checking that
needs to happen.

Well, in some cases - but not in others. ADO.NET is a very broad
example :)

Of course, in the below example, I am trying to use the
last level (HelpMePlease instance), but I need to make sure that all those
levels above it are non-null first, otherwise I get the null exception.
>
Perhaps I expect that some of these could be null a significant number of
times during execution. It seems to be a sort of hack to just wrap the whole
thing in a try-catch and then continue on. After all, I would like to
reserve exceptions for those cases when something unexpected occured and I
can take remedial actions.

Oh you certainly shouldn't do that, no :)

If you often need to do this for a particular "tree" of properties, you
could put it into a static helper method in the top-level class, but
basically you need all the tests you've got, if every property can
legitimately be null.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[ssamuel]

Re: Multiple levels of Null Checking

Karch,

This may be an architectural red flag. Sometimes, I find myself
writing:

if (SomeObject != null && SomeObject.Anot herObject != null)
DoSomething();

but I've rarely gone past two levels. Having 4-level-deep objects is a
sign that either you're working on an incredibly complex system, or
you've mis-designed your object model. I've built some incredibly
complex systems and they still don't go past two levels.

Incidentally, typed DataSets as created by the VS.NET tools make you
dig pretty deep and run into issues like this sometimes. I personally
believe this is an architectural problem, and that object references to
deep structured data, as opposed to things like XPath/XQuery, is
generally difficult. Prime evidence of this is the renaming that you
need to do to make sure nothing collides in your typed DataSet.
Microsoft seems to agree, because they're fixing this in .NET 3.0 with
LINQ.

That having been said, one possible solution is validation. I'm
assuming SomeObject.Anot herObject is a property, not that AnotherObject
is a public member. If it's a public member, it probably shouldn't be.
By making it a property, you can assure that it's not null on the way
in, so you don't have to check it later.

Another way around is a solid contract check:

if (SomeObject == null)
return "Sorry, invalid";

// Now we know SomeObject is not null.
if (SomeObject.Ano therObject == null)
return "Sorry, invalid."

// etc.

It's more code, but it's easier to read and maintain. You can comment
each line, and you can do better value-add checks (e.g. -- SomeObject
== null || SomeObject.Leng th 5). If you're unit testing (you're unit
testing, right? I hope you are if it's an incredibly complex system),
this is the easiest way to make sure your code passes now and will pass
later.

Otherwise, it's not bad to implement IDisposable. If your objects are
using resources -- they probably should be otherwise you've likely made
your object model too deep -- it's the best way to free them up without
burdening the user with Close()-ing your objects. Learn the pattern for
IDisposable and C#-style destructors and you'll be building more robust
code anyway.

HTH.

Stephan



Karch wrote:

I find myself doing things like this all the time:
>
if (
SomeObject != null &&
SomeObject.Anot herObject != null &&
SomeObject.Anot herObject.YetAn other != null &&
SomeObject.Anot herObject.YetAn other.HelpMePle ase != null)
{
// Do Something
}
>
Surely there must be a better way that I am missing? I thought about the
using statement, but that of course depends upon the IDisposable interface
being implemented, right?
>
Thanks!

[Mark Wilden]

Re: Multiple levels of Null Checking

"Jon Skeet [C# MVP]" <skeet@pobox.co mwrote in message
news:MPG.1fc42c 3aedf18c9698d60 2@msnews.micros oft.com...

>SomeObject != null &&
>SomeObject.Ano therObject != null &&
>SomeObject.Ano therObject.YetA nother != null &&
>SomeObject.Ano therObject.YetA nother.HelpMePl ease != null)

As
another point, I rarely end up using properties 4 levels deep - I
usually try to design classes so that I can ask one class to do what
I'm interested in, without going through several levels.

Thus adhering to the "Law" of Demeter, which I generally try to do, as well.

///ark

[Bob Jones]

Re: Multiple levels of Null Checking

I'm thinking you could implement the concept of "null objects". The
net effect of it is that code using the object doesn't do null
checking; it doesn't have to.

In other words you instantiate an object but it's property or method
has "do nothing" behavior. It returns whatever value is appropriate
for "empty" or "nothing returned" or "none" or simply do nothing, or
whatever. Thus you never actually get "null" and the client code
doesn't have to explicty do a null check/trap.

The null object idea is actually a design pattern. You define an
abstract class then have both the "real" object and the "null" object
inherit from it. Thus your client code never knows (or cares) when it's
getting a null object.

On 2006-11-14 13:19:07 -0600, "Karch" <nospam@absotut ely.comsaid:

I find myself doing things like this all the time:
>
if (
SomeObject != null &&
SomeObject.Anot herObject != null &&
SomeObject.Anot herObject.YetAn other != null &&
SomeObject.Anot herObject.YetAn other.HelpMePle ase != null)
{
// Do Something
}
>
Surely there must be a better way that I am missing? I thought about
the using statement, but that of course depends upon the IDisposable
interface being implemented, right?
>
Thanks!

[ssamuel]

Re: Multiple levels of Null Checking

Bob,

Clever. The use of structs (which are not nullable) is a converse but
similar implementation.


Stephan


Bob Jones wrote:

I'm thinking you could implement the concept of "null objects". The
net effect of it is that code using the object doesn't do null
checking; it doesn't have to.
>
In other words you instantiate an object but it's property or method
has "do nothing" behavior. It returns whatever value is appropriate
for "empty" or "nothing returned" or "none" or simply do nothing, or
whatever. Thus you never actually get "null" and the client code
doesn't have to explicty do a null check/trap.
>
The null object idea is actually a design pattern. You define an
abstract class then have both the "real" object and the "null" object
inherit from it. Thus your client code never knows (or cares) when it's
getting a null object.
>
On 2006-11-14 13:19:07 -0600, "Karch" <nospam@absotut ely.comsaid:
>

I find myself doing things like this all the time:

if (
SomeObject != null &&
SomeObject.Anot herObject != null &&
SomeObject.Anot herObject.YetAn other != null &&
SomeObject.Anot herObject.YetAn other.HelpMePle ase != null)
{
// Do Something
}

Surely there must be a better way that I am missing? I thought about
the using statement, but that of course depends upon the IDisposable
interface being implemented, right?

Thanks!

[Michael C]

Re: Multiple levels of Null Checking

"Karch" <nospam@absotut ely.comwrote in message
news:%23LBC8GCC HHA.4764@TK2MSF TNGP03.phx.gbl. ..

>I find myself doing things like this all the time:
>
if (
SomeObject != null &&
SomeObject.Anot herObject != null &&
SomeObject.Anot herObject.YetAn other != null &&
SomeObject.Anot herObject.YetAn other.HelpMePle ase != null)
{
// Do Something
}
>
Surely there must be a better way that I am missing? I thought about the
using statement, but that of course depends upon the IDisposable interface
being implemented, right?

This is probably no different to any other code you need to repeat over and
over. If it gets used many times, put it in a function.

Michael