1.4.20 Checking Whether an Object Reference Is Null

Object References Can Either Reach an Object or Be null

You have already seen reference fields such as:

public Team team;

A Team field can refer to a Team object:

player1.team = team1;

or it can contain:

null

When the value is null, the reference does not currently point to a Team object.

Why a Null Check Matters

Suppose code tries to execute:

player1.team.DisplayName();

If:

player1.team = null

the program cannot reach a Team object to call DisplayName().

That can produce a:

NullReferenceException

Before using the referenced object, code can test whether the reference is null.

Compare the Reference with null

A simple condition is:

if (player1.team == null)
{
    System.Console.WriteLine("No team has been assigned.");
}

The condition:

player1.team == null

is a Boolean expression.

It evaluates to:

true

when the Team reference is null.

It evaluates to:

false

when the reference points to a Team object.

Read the Condition in Plain Language

Read:

player1.team == null

as:

That question produces a Boolean result.

The if statement then chooses whether its block should run.

Use the Check Before Member Access

A useful process is:

Object diagram showing inspect the reference, then is it null?, then yes handle the missing relationship, then no the related object can be used.
InspectTheReference.
  • New
  • Changed
  • Removed

For example:

if (player1.team == null)
{
    System.Console.WriteLine("No team has been assigned.");
}

This code detects the missing reference.

The exact action you take after detecting it depends on the current requirement.

A Null Check Does Not Create the Missing Object

This condition:

player1.team == null

only tests the reference.

It does not create a Team.

It does not assign a Team.

It does not repair the relationship automatically.

Keep these operations distinct:

Test
player1.team == null
Create
Team team1 = new Team();
Connect
player1.team = team1;

The model and requirement determine which action is appropriate.

Do Not Replace a Required Relationship with a Permanent Null State

Suppose the UML says:

player1 : Player -------- team1 : Team

That model expects the objects to be connected.

A null check can help detect that the relationship has not been established.

It should not become an excuse to leave the model incomplete.

The intended object relationship still needs to be created when the requirement calls for it.

Null Is Different from an Object Whose Fields Are Empty

Consider:

Team team1 = new Team();
player1.team = team1;

Now:

player1.team

is not null.

The Team object may still have fields containing default values, such as:

name = null

Those are two different situations:

player1.team = null

means there is no Team object through that reference.

player1.team → Team object with name = null

means the Team object exists, but one of its fields has not been assigned a non-null value.

Use the Debugger to Observe the Difference

Pause before the null test and inspect:

player1.team

You may see:

null

or an expandable Team object.

That runtime evidence tells you how the condition should evaluate.

Keep the Current Goal Focused

Later activities introduce additional conditional operators and more complex Boolean logic.

For now, the important pattern is:

objectReference == null

and the reasoning behind it: