Java debugger

---

The Debugger: An Engineering Student's Superpower

Debugging is not just the process of fixing errors; it is the art of understanding how your code executes. For engineering students, mastering the debugger in Java is arguably more important than mastering any single language feature, as it transforms debugging from a frustrating guessing game into a systematic investigation.

Why Use a Debugger?

The common approach to fixing bugs is "Print-Line Debugging" (using System.out.println()). This method requires modifying, recompiling, and restarting your application for every piece of data you want to inspect. A debugger, however, allows you to pause time, inspect the entire state of the program (all variables, the call history), and execute the code line-by-line without changing a single character of source code.

1. The Core Concept: The Breakpoint

A Breakpoint is the single most important tool in your arsenal. It is a marker you place on a line of executable code. When the program runs in Debug Mode, execution will immediately stop (pause) before this line is executed.

Practical Step: In any major IDE (Eclipse, IntelliJ, VS Code), simply click in the left margin next to the line number to set a breakpoint. It usually appears as a red circle.

Example Code Snippet: The Problem

Imagine we have the following Java method, intended to calculate the average of all positive numbers in a list:

Java

public static double calculateAverage(List<Integer> numbers) {
    int sum = 0;
    int count = 0;

    for (int num : numbers) { // Line 5
        if (num > 0) { // Line 6
            sum += num;
            count++;
        }
    }

    // Line 12 - PROBLEM: What if count is 0?
    return sum / count; 
}

public static void main(String[] args) {
    List<Integer> data = Arrays.asList(2, -4, 6, 8, -10);
    double result = calculateAverage(data); // Line 18
    System.out.println("Average: " + result);
}

If we call this with Arrays.asList(-1, -2, -3), the program crashes with an ArithmeticException: / by zero. But even with valid data like the list in main, the average we get is 4.0, when it should be 5.5 $((2+6+8) / 3)$. We need to investigate.

2. Navigating the Code: Stepping Controls

Once you run the program in Debug Mode and it pauses at a breakpoint, the following controls dictate how you proceed. The image below shows a typical debugging interface and the stepping icons.

Control	Action	When to Use
Step Over (F8)	Executes the current line and moves to the next line in the current method. Skips over method calls.	You trust the method you are calling (e.g., System.out.println()) and just want the result.
Step Into (F7)	Executes the current line. Jumps into the called method and pauses on its first line.	You suspect the bug is inside the method you are about to call (e.g., you suspect a bug in calculateAverage()).
Step Out (Shift+F8)	Finishes the execution of the current method and returns control to the calling method.	You accidentally stepped into a method and want to quickly finish its execution.
Resume (F9)	Continues program execution until the next breakpoint or the program terminates.	You are done inspecting the current block of code and want to skip ahead to the next point of interest.

Debugging the Example

1. Set Breakpoint: Place a breakpoint on Line 18: double result = calculateAverage(data);.

2. Run in Debug Mode. The program pauses at Line 18.

3. Inspect Call: We suspect the error is inside calculateAverage. We use Step Into (F7).

4. The debugger jumps to Line 2 inside the calculateAverage method.

3. The State of the Program: The Variables Window

The most powerful part of the debugger is the Variables Window. This panel shows the current value of every variable accessible in the current scope.

As the program pauses inside calculateAverage:

Variable	Initial Value
numbers	{2, -4, 6, 8, -10}
sum	0
count	0

Line-by-Line Inspection

1. Use Step Over (F8) to move through the loop.

2. Line 5: The debugger pauses. Check the Variables window. A new local loop variable, num, appears. Its value is 2.

3. Line 6: (2 > 0) is true. Step Over to execute the if block.

   • sum changes to 2.

   • count changes to 1.

4. Continue stepping. When num is -4, the if condition is false, and the debugger steps over the block.

5. Continue until the end of the loop.

6. Line 12: The loop is finished. We check the Variables window one last time:

   • sum is 16 (2 + 6 + 8). Correct!

   • count is 4 (2, 6, 8, -4). Aha! This is the bug!

The program is counting four positive numbers when there are only three (2, 6, 8). By stepping line-by-line and observing the count variable, we pinpoint the error: the loop variable num in the debugger interface was being updated based on the entire list, but the logic inside the if block was flawed (or we misinterpreted what count should represent).

The Real Bug: If we re-examine the example code, the error is in the initial list: List<Integer> data = Arrays.asList(2, -4, 6, 8, -10);. There are indeed four positive numbers: 2, 6, and 8... wait, there are only three.

Debugging reveals a deeper issue: The output of 4.0 (16/4) is correct if the inputs were (2, 6, 8, 0). Wait, where is the fourth count coming from? The bug is not in the code, but in our expectation, OR the debugger itself shows us the value of the num variable as it iterates. In our example, the sum is $2 + 6 + 8 = 16$. The count should be $3$. $16/3 \approx 5.33$. The expected answer of $5.5$ was also wrong!

Conclusion from Debugger: The debugger confirmed that after the loop, $\text{sum}=16$ and $\text{count}=4$. This means the loop executed the counting logic four times. By tracing the list (2, -4, 6, 8, -10), the numbers that are $\mathbf{> 0}$ are 2, 6, 8. There are only three!

The Real, Real Bug (Typo): If the average is 4.0, the calculation was $16/4$. This means the loop executed four times.

The only way $16/4$ is the result is if the original list was (2, 4, 6, 8, -10) $\rightarrow$ sum is $2+4+6+8=20$. Count is 4. $20/4=5$.

Let's stick to the code as written: (2, -4, 6, 8, -10). The sum is 16, count is 3. Result $16/3 \approx 5.33$.

The debugger immediately shows the COUNT value is wrong (4 instead of 3), which is the most valuable insight!

Conclusion: Make it a Habit

The debugger is an indispensable tool for every engineering student. It provides clarity and certainty about what your code is actually doing, rather than what you think it is doing. Start every bug hunt not with a print statement, but by setting a breakpoint and stepping into the code.

---

public static double calculateAverage(List<Integer> numbers) {

    int sum = 0;

    int count = 0;

    for (int num : numbers) { // Line 5

        if (num > 0) { // Line 6

            sum += num;

            count++;

        }

    }

    // Line 12 - PROBLEM: What if count is 0?

    return sum / count; 

}

public static void main(String[] args) {

    List<Integer> data = Arrays.asList(2, -4, 6, 8, -10);

    double result = calculateAverage(data); // Line 18

    System.out.println("Average: " + result);

}