1.5.20 Debugging Nested and Conditional Returns

Before stepping into the conditions, inspect:

this.isAvailable
this.position

Suppose:

isAvailable = true
position = "Goalkeeper"

Predict:

outer if → true
inner if → true
return "Available goalkeeper"

Then use the debugger to test that prediction.

For nested conditions, do not jump directly to the return you expect.

Follow execution order:

outer condition
   ↓
selected branch
   ↓
inner condition if reached
   ↓
selected return

This prevents you from attributing a return to a condition that was never evaluated.

Suppose the method is:

public string GetTeamName()
{
    if (this.team == null)
    {
        return "No team";
    }

    return this.team.name;
}

If:

this.team = null

the first return should execute.

The method should end before reaching:

return this.team.name;

If you expect the later return to run too, your mental model of return is incorrect.

A useful debugger workflow is:

The debugger makes both the conditional path and return path visible.

While inside the returning method, the Call Stack contains that method above its caller.

After the return executes, the method leaves the active stack and the caller resumes.

That is evidence that the return ended the current method.

Suppose:

public string GetGoalCategory(int goals)
{
    if (goals >= 3)
    {
        return "Two goals";
    }

    return "Fewer than three";
}

For:

goals = 4

the condition correctly selects the first branch.

The wrong string is returned.

The defect is in the returned value, not in the condition.

Now suppose:

public string GetGoalCategory(int goals)
{
    if (goals > 3)
    {
        return "High scoring";
    }

    return "Fewer than three";
}

For:

goals = 3

the first condition is false.

If the requirement says 3 should count as high scoring, the defect is the comparison boundary.

The returned strings may be correct for their branches, but the wrong branch is selected.

Suppose C# reports that not all code paths return a value:

public string GetAvailabilityText()
{
    if (this.isAvailable)
    {
        return "Available";
    }
}

Trace both possibilities.

Suppose:

public string GetTeamName()
{
    if (this.team == null)
    {
        return "No team";
    }

    return this.team.name;
}

The caller unexpectedly receives:

"No team"

Inspect:

this.team

If it is null, the return is consistent with the current runtime state.

The actual defect may be earlier, where the Team relationship should have been assigned.

A returned result may depend on:

When the result is wrong, work backward.

For example:

wrong returned string
      ↑
selected return statement
      ↑
selected conditional branch
      ↑
Boolean expression
      ↑
runtime field/parameter values

This helps locate the earliest incorrect state or decision.

A returning conditional method is not well understood after testing only one input.

For a method with three possible returns, inspect representative values that reach each return.

For example:

goals = 4 → high-scoring return
goals = 2 → two-goal return
goals = 0 → remaining return

The purpose is to understand each path, not merely the most common one.

CO-046 focuses on value returns such as:

int
double
bool
string

Returning object references is taught later.

Keep the debugging target within the current module boundary.

A strong explanation sounds like:

That explanation connects runtime state, decision logic, return flow, and requirement.