Multiple levels of Null Checking

[Karch]

I find myself doing things like this all the time:

if (
SomeObject != null &&
SomeObject.AnotherObject != null &&
SomeObject.AnotherObject.YetAnother != null &&
SomeObject.AnotherObject.YetAnother.HelpMePlease != 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]]

I find myself doing things like this all the time:

if (
SomeObject != null &&
SomeObject.AnotherObject != null &&
SomeObject.AnotherObject.YetAnother != null &&
SomeObject.AnotherObject.YetAnother.HelpMePlease != 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
NullReferenceException 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.

 

[Rad]

I find myself doing things like this all the time:

if (
SomeObject != null &&
SomeObject.AnotherObject != null &&
SomeObject.AnotherObject.YetAnother != null &&
SomeObject.AnotherObject.YetAnother.HelpMePlease != 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]

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.AnotherObject is null.
That is the order that he is checking.

 

[Jon Skeet [C# MVP]]

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.AnotherObject
will throw a NullReferenceException, which is what the OP is presumably
trying to avoid.

Shameless plug - you could do it in Groovy:
if (SomeObject?.AnotherObject?.YetAnother?.HelpMePlease != null)
{
....
}

 

[Tom Porterfield]

Shameless plug - you could do it in Groovy:
if (SomeObject?.AnotherObject?.YetAnother?.HelpMePlease != null)
{
....
}

groooooovy.

 

[Karch]

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.

 

[Rad]

Yes, but SomeObject could be not null yet SomeObject.AnotherObject 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]]

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.Encoding.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.

 

[ssamuel]

Karch,

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

if (SomeObject != null && SomeObject.AnotherObject != 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.AnotherObject 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.AnotherObject == 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.Length > 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

 

[Mark Wilden]

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]

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.

 

[ssamuel]

Bob,

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


Stephan

 

[Michael C]

I find myself doing things like this all the time:

if (
SomeObject != null &&
SomeObject.AnotherObject != null &&
SomeObject.AnotherObject.YetAnother != null &&
SomeObject.AnotherObject.YetAnother.HelpMePlease != 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