Module 4: Exception Handling & Debugging

In the enterprise world, code isn’t judged just by how it works when things go right, but by how it behaves when things go wrong. Exception Handling is the art of “failing gracefully.” If a database connection drops or a user enters a string where a number should be, your app shouldn’t just crash—it should log the error and recover.

1. Try–Catch–Finally: The Safety Net

This is the fundamental structure for handling runtime errors.

• try: The block where you put “risky” code that might throw an error (e.g., opening a file, calling an API).
• catch: The block that executes only if an error occurs. You can have multiple catch blocks for different types of errors (e.g., one for FileNotFoundException and another for SqlException).
• finally: The “cleanup” block. It runs no matter what—whether an error happened or not. This is where you close database connections or file handles to prevent “memory leaks.”

2. Custom Exceptions

Sometimes, standard .NET exceptions like IndexOutOfRangeException don’t describe a specific business problem. For example, in a banking app, “Insufficient Funds” is a specific business error, not a technical one.

• How to create one: You create a new class that inherits from the base Exception class.
• Why use them: They make your code more readable. When a developer sees throw new InsufficientFundsException(), they immediately understand the business context of the failure.

3. Global Exception Handling

In a large application with thousands of lines of code, you cannot put every single line inside a try-catch block (this is called “Pokemon Exception Handling”—trying to catch ’em all—and it’s considered bad practice).

Global Exception Handling is a “catch-all” mechanism at the highest level of your application.

• In Web APIs: We use “Middleware.”
• In Desktop Apps: We use the AppDomain.UnhandledException event.
• Purpose: It ensures that if an unexpected error slips through, the app logs the details and shows a friendly “Oops, something went wrong” message to the user instead of showing a scary technical stack trace.

4. Debugging Tools in Visual Studio

Debugging is the process of pausing time to inspect the “brain” of your application while it’s running.

• Breakpoints (F9): Red dots that tell the program: “Stop right here so I can look around.”
• Step Over (F10): Move to the next line of code.
• Step Into (F11): If the current line is a method, jump inside that method to see what it does.
• Watch Window: A small panel where you can type variable names and watch their values change in real-time.
• Immediate Window: A “command prompt” where you can execute C# code while the app is paused to test fixes.

5. Logging Basics

In a production environment (on a server), you don’t have a “Debugger.” You can’t see what’s happening. Logging is your “Black Box” flight recorder.

• Log Levels:
  • Information: General flow (e.g., “User logged in”).
  • Warning: Something unusual happened, but the app is still running.
  • Error: Something failed (e.g., “Failed to send email”).
  • Critical: The app is crashing!
• Tools: In .NET, we typically use the built-in ILogger interface, often paired with “Sinks” like Serilog or NLog to save logs to a file, a database, or the cloud (Azure Application Insights).

Outcome: Building Resilient Apps

By the end of this module, you stop writing “happy path” code. You begin to anticipate failure. You write code that:

1. Expects things to break.
2. Provides meaningful feedback when they do.
3. Cleans up resources to prevent server crashes.
4. Leaves a “paper trail” (logs) so you can fix bugs you weren’t there to see.