Debugging C# Code: A Beginner's Guide

Your Tip Calculator from Lesson 6 crashes when someone types "free lunch" instead of a number. Your balance API from Lesson 7 returns zero for every account. Welcome to the part every developer lives in — debugging.

Debugging is not proof you failed. It is how you investigate crime scenes in code: read clues, test theories, fix the culprit. Even engineers building banking and Netflix-scale systems spend hours in the debugger. You are in good company.

Two Types of Errors

Compile-time errors — the build stops before running. Missing semicolon, typo in a type name. Visual Studio underlines them in red. Fix the syntax and rebuild.

Runtime errors — the app starts, then crashes or misbehaves. Example from Lesson 6:

double bill = double.Parse(Console.ReadLine()); // throws if input is not a number

The compiler was happy. The user input was not. That is runtime — and where breakpoints shine.

Reading Error Messages

When .NET throws an exception, it prints a stack trace — a trail of method calls leading to the crash. Read top to bottom:

• Exception type — e.g. FormatException (bad string-to-number conversion)
• Message — plain-English hint
• Stack frames — file names and line numbers

Start at the first line that mentions your project code, not framework internals. That is usually where you fix the problem or add validation.

Breakpoints: Pause and Look Around

A breakpoint is a red dot on a line. When execution reaches it, the program freezes so you can inspect variables — like pausing a Netflix show to read the subtitle you missed.

In VS Code or Visual Studio: click the gutter next to a line, press F5 to start debugging, trigger the code path. When paused:

• Locals / Watch — see variable values
• F10 (Step Over) — run line, stay at same level
• F11 (Step Into) — dive inside a method call
• F5 (Continue) — run until next breakpoint

Worked Example: Wrong Total

double bill = 500;
int tipPercent = 10;
double tipAmount = bill * tipPercent;  // Bug: should divide by 100
double total = bill + tipAmount;

Console.WriteLine("Total: " + total);

Expected total: 550. Actual: 5500. Set a breakpoint before Console.WriteLine. Inspect tipAmount — it is 5000, not 50. The formula missed / 100.0. You found the bug without guessing.

Debugging Flow

Bug reported / app crashes
      ↓
Reproduce the problem reliably
      ↓
Read error message or set breakpoint
      ↓
Inspect variables vs expectations
      ↓
Fix code → run again → verify

Reproducing the bug is step one. If you cannot trigger it consistently, you are guessing in the dark — like trying to fix a WhatsApp notification that "sometimes" fails without knowing which phone or network.

Defensive Fixes Worth Learning Now

string input = Console.ReadLine() ?? "";

if (!double.TryParse(input, out double bill))
{
    Console.WriteLine("Please enter a valid number.");
    return;
}

TryParse avoids exceptions by returning false when input is invalid — a pattern you will use in APIs accepting JSON from mobile apps.

Debugging ASP.NET Core APIs

Set a breakpoint inside your endpoint or injected service from Lesson 9. Start the project with the debugger (F5). Send a request with a browser or Postman. Execution pauses inside your C# — inspect EF queries, service results, and returned JSON before it leaves the server.

Check the terminal for logged errors. ASP.NET Core logs unhandled exceptions with stack traces — your first clue when a breakpoint is not yet set.

Common Misconceptions

"Good developers do not get bugs." They get bugs constantly. They are good at finding them quickly.

"Console.WriteLine is enough forever." Fine for tiny scripts. Breakpoints scale better when logic branches across many methods.

"I should change five things at once to save time." Change one thing, rerun, observe. Multiple changes hide which fix worked.

"Exceptions are always bad." Exceptions signal failure paths. Catching them thoughtfully (invalid user input) is good design. Letting them crash production is not.

Quick Recap

• Compile errors block the build; runtime errors happen during execution.
• Read stack traces from the top — find your code in the list.
• Breakpoints pause execution so you can inspect state.
• Reproduce bugs reliably before fixing.
• Use TryParse and validation to handle bad input gracefully.

Summary

Debugging is detective work with a pause button. You have travelled from .NET fundamentals to web APIs, databases, and dependency injection — debugging ties it all together when reality does not match your plan.

Think of it like a bank's fraud team reviewing a flagged transaction: gather evidence, trace the path, fix the rule, test again. You now have the beginner toolkit. Keep building — intermediate topics like authentication, testing, and Azure deployment await when you are ready.