Debugging C# Programs

A compile-time error prevents a program from being built: syntax is invalid, a name is unknown, or types do not fit. A runtime exception occurs after execution starts, such as indexing beyond an array. A logic error produces a result but the result is wrong. The compiler cannot know that a discount rule or average formula contradicts your requirement.

Classifying the symptom narrows the investigation. For a compiler error, inspect the message and nearby code. For an exception, read its type, message, and stack trace. For wrong output, compare expected and actual state at each important step.

A useful bug report says which input produces which result and what should happen instead. ‘The total is broken’ is difficult to test. ‘Quantities 2 and 3 produce 5.00, but with price 4.00 the total should be 20.00’ gives you a repeatable case and an expected value.

Reduce the input while preserving the failure. Small cases are easier to calculate by hand and produce less output. Do not change five lines at once; each change creates another possible cause.

A debugger pauses a running program without requiring you to edit its output. Set a breakpoint on an executable line near the suspected failure, start debugging, reproduce the input, and inspect the program state before changing code. The highlighted line is normally the next statement to execute, not one that has already completed.

Use Step Over when you want a method call to run as one operation. Use Step Into when the bug may be inside that method, and Step Out when you have learned enough and want to return to the caller. A Watch keeps a chosen variable or expression visible; the Call Stack shows which chain of methods led to the current line. Shortcut keys vary by editor, so learn the commands as concepts first.

Temporary Console.WriteLine statements can reveal the value before and after an update. A debugger provides breakpoints, step controls, watches, and variable inspection without changing output. Both approaches answer the same question: what did the program know at this moment?

For loops, print the counter, condition-relevant state, and accumulated result. For conditions, print the smaller Boolean facts. Remove noisy diagnostic output after the cause is understood, or replace it with deliberate application logging when it has ongoing operational value.

int total = 0;

for (int number = 1; number <= 3; number++)
{
  total += number;
  Console.WriteLine($"number={number}, total={total}");
}

number=1, total=1
number=2, total=3
number=3, total=6

Test the smallest valid value, largest valid value, just outside each boundary, an empty collection, and one normal middle value. For a rule from 1 through 10, try 0, 1, 5, 10, and 11. This is more informative than repeating several comfortable middle values.

After fixing the failure, run the original case and nearby cases. A change that fixes one input by hardcoding its answer is not a real fix. The goal is to correct the rule that connects the whole valid input space to the output.