1.4.29 Tracing Parameter Values in the Debugger

The Debugger Can Show What Value a Method Actually Received

A parameter gets its value from the argument supplied by the caller.

Consider:

player1.SetJerseyNumber(7);

and:

public void SetJerseyNumber(int number)
{
    this.jerseyNumber = number;
}

You can use the debugger to observe the value crossing that method-call boundary.

Pause at the Call

Set a breakpoint near:

player1.SetJerseyNumber(7);

Before entering the method, identify the argument:

Predict:

Now you have an expected value.

Step Into the Method

Use Step Into at the method call.

When execution moves into:

SetJerseyNumber(int number)

inspect:

number

The debugger should show the value received for this call.

Conceptually:

Activity diagram showing caller argument 7, then method parameter number = 7. — CallerArgument.

Compare the Parameter with the Caller Expression

The argument does not have to be a literal.

Suppose:

int selectedNumber = 9;
player1.SetJerseyNumber(selectedNumber);

Before the call, inspect:

selectedNumber = 9

Then step into the method.

Inside, inspect:

number = 9

The names differ.

The value passed from caller to parameter is the connection.

Trace Multiple Parameters by Position

Suppose:

player1.SetPlayerInfo("Jordan", 7);

and:

public void SetPlayerInfo(string name, int number)
{
    this.name = name;
    this.jerseyNumber = number;
}

Predict:

name = "Jordan"
number = 7

After stepping into the method, inspect both parameters.

The debugger should show the values associated with that specific call.

Trace a Boolean Parameter

For:

player1.SetAvailability(false);

and:

public void SetAvailability(bool available)
{
    if (!available)
    {
        System.Console.WriteLine("Unavailable");
    }
}

inside the method, inspect:

available = false

Then evaluate:

!available

as:

!false → true

Parameter tracing and Boolean-expression tracing work together.

Parameters Are Specific to the Active Call

Suppose the method is called twice:

player1.SetJerseyNumber(7);
player1.SetJerseyNumber(12);

The parameter value depends on which call is currently active.

First call:

number = 7

Second call:

number = 12

Do not assume a parameter has one permanent value.

It receives a value for each method invocation.

The Call Stack Helps Identify the Caller

While paused inside a parameterized method, the Call Stack can help answer:

This is useful when the same method can be called from several locations.

Combine:

the current parameter value;
the current source location;
the active caller.

Together they explain the runtime path.

Trace a Forwarded Parameter

Suppose:

public void SendTeamMessage(string message)
{
    this.team.DisplayMessage(message);
}

and the caller uses:

player1.SendTeamMessage("Practice starts at 5.");

Inside SendTeamMessage, inspect:

message = "Practice starts at 5."

Then step into:

this.team.DisplayMessage(message);

Inside the Team method, inspect its parameter.

You can observe the same text value being forwarded across another method-call boundary.

Do Not Confuse Parameters with Fields

Inside:

public void SetJerseyNumber(int number)
{
    this.jerseyNumber = number;
}

the debugger may show:

number = 7
this.jerseyNumber = 0

before the assignment executes.

After stepping over the assignment:

number = 7
this.jerseyNumber = 7

The parameter value existed first.

The field changed when the assignment executed.

This makes the difference between method input and object state visible.

A Parameter Can Be Correct Even When the Resulting Behavior Is Wrong

Suppose the debugger confirms:

number = 7

but the wrong field is assigned:

this.score = number;

The argument and parameter flow are correct.

The defect is in how the method uses the parameter.

Tracing lets you isolate the part that is actually wrong.

Build a Runtime Explanation

A strong explanation can be:

That explanation connects:

caller;
argument;
parameter;
field;
execution;
observed state.

The Main Trace

Use this sequence:

Activity diagram showing identify argument, then predict parameter value, then step into method, then inspect parameter, then follow how method uses it, then inspect resulting state. — IdentifyArgument.

This gives you direct runtime evidence for how information moves into a method.