C# Exception Handling Explained — try, catch, finally and Real Patterns

Every real application deals with the unexpected. Files get deleted, APIs time out, users type letters where numbers should go, and databases go offline at 2 AM. If your code has no plan for these moments, the result is a crash with a cryptic error message — or worse, silent data corruption. Exception handling is the mechanism that separates production-grade code from a weekend script that only works when nothing goes wrong.

Before exception handling existed in mainstream languages, developers had to check every single return value manually — imagine calling a function and having to verify 'did that succeed? did THAT succeed?' after every single line. It was error-prone, repetitive, and easy to miss. The try/catch model solves this by letting you separate your happy-path logic from your error-handling logic cleanly, so both are easier to read and maintain.

By the end of this article you'll understand not just the syntax of try, catch, finally, and throw — but when to use each one, how to build custom exceptions that carry real diagnostic information, and the patterns senior developers actually use in production code. You'll also learn the mistakes that cause subtle bugs even in code that 'looks' like it handles errors correctly.

How try/catch/finally Actually Works in C#

Exception handling in C# is a structured mechanism for propagating errors from a throw site to a matching catch block, bypassing normal control flow. The core mechanic: when code throws an exception, the runtime unwinds the call stack, executing any intervening finally blocks, until it finds a catch block whose filter matches the exception type. If none matches, the process repeats up the stack until the AppDomain's unhandled exception handler terminates the process.

Key properties that matter in practice: catch blocks are type-checked at runtime, not compile time, so order matters—place more specific exception types before general ones. Finally blocks execute unconditionally, even if the catch block rethrows or the thread is aborted via ThreadAbortException (though not for StackOverflowException or Environment.FailFast). The using statement compiles to try/finally, ensuring Dispose is called even on exception. Performance-wise, the try block itself has near-zero cost; the overhead is in the throw and stack-walk, which can be 10-100x slower than a normal return.

Use exception handling for exceptional, unpredictable failures—network timeouts, missing files, null references from external data—not for control flow. In real systems, catching Exception broadly hides bugs and makes debugging impossible. The rule: catch specific exceptions you can actually handle, let everything else crash fast so monitoring catches it.

The try/catch Block — Catching Errors Before They Crash Your App

The core idea is simple: you wrap the code that might fail in a 'try' block, and you describe what to do if it fails in a 'catch' block. If everything in 'try' succeeds, the 'catch' block is completely skipped. If anything throws an exception, execution jumps immediately to the matching 'catch' block — no more lines in 'try' run after the failure point.

The important word there is 'matching'. C# exceptions are organized in a class hierarchy, so you can catch specific types — like 'FileNotFoundException' — or broader ones like 'IOException', which covers a whole family of file-related errors. You should always catch the most specific exception you can handle. Catching everything with a bare 'Exception' at the top is the coding equivalent of saying 'if anything ever goes wrong, just shrug' — it hides bugs you should be fixing.

Notice in the example below how we catch two different exception types with two separate catch blocks. The order matters: C# evaluates them top to bottom and uses the first one that matches. If you put 'Exception' at the top, it will swallow everything and the specific catches below it will never fire — the compiler actually warns you about this.

using System;
using System.IO;

class FileReaderExample
{
    static void Main()
    {
        // The path we're going to try reading from
        string configFilePath = "appsettings.json";

        try
        {
            // This is the 'happy path' — what we want to happen
            string fileContents = File.ReadAllText(configFilePath);
            Console.WriteLine("Config loaded successfully:");
            Console.WriteLine(fileContents);
        }
        catch (FileNotFoundException notFoundEx)
        {
            // Fires ONLY when the specific file doesn't exist
            // notFoundEx.FileName gives us the exact path that was missing
            Console.WriteLine($"Config file missing: {notFoundEx.FileName}");
            Console.WriteLine("Loading default settings instead...");
        }
        catch (UnauthorizedAccessException accessEx)
        {
            // Fires when the file exists but we don't have permission to read it
            Console.WriteLine($"Permission denied reading config: {accessEx.Message}");
        }
        catch (IOException ioEx)
        {
            // Catches any other I/O problem (disk error, network drive gone, etc.)
            // This is broader than the two above, so it comes AFTER them
            Console.WriteLine($"Unexpected I/O error: {ioEx.Message}");
        }

        // This line runs regardless of whether an exception occurred
        Console.WriteLine("Application startup continues...");
    }
}

The finally Block — Code That ALWAYS Runs, No Matter What

Here's a scenario: you open a database connection, then an exception fires halfway through your query. The catch block runs — great. But what about closing the database connection? If you only close it at the bottom of the try block, it never gets cleaned up when an exception occurs. You've just leaked a resource.

That's exactly what 'finally' is for. Code inside a 'finally' block runs whether the try succeeded, whether a catch ran, or even if you hit a 'return' statement inside the try. It's the guaranteed cleanup crew. Think of it as the bouncer at the door who makes sure the lights get turned off no matter how the party ends.

In modern C#, you'll often use 'using' statements instead of manual try/finally for objects that implement IDisposable — 'using' compiles down to a try/finally under the hood. But for non-disposable resources, or when you need custom cleanup logic, an explicit 'finally' block is the right tool. The example below shows a realistic database scenario where connection cleanup is non-negotiable.

using System;
using System.Data.SqlClient;

class DatabaseQueryExample
{
    static void Main()
    {
        // In production this comes from config, not hardcoded
        string connectionString = "Server=localhost;Database=ShopDb;Trusted_Connection=True;";
        SqlConnection dbConnection = null;

        try
        {
            dbConnection = new SqlConnection(connectionString);
            dbConnection.Open(); // Could throw SqlException if server is unreachable

            Console.WriteLine("Connection opened. Running query...");

            // Simulate a query that might fail
            SqlCommand command = new SqlCommand("SELECT * FROM NonExistentTable", dbConnection);
            SqlDataReader reader = command.ExecuteReader(); // Throws SqlException here

            Console.WriteLine("Query complete.");
        }
        catch (SqlException sqlEx)
        {
            // sqlEx.Number gives the SQL Server error code — useful for logging
            Console.WriteLine($"Database error #{sqlEx.Number}: {sqlEx.Message}");
        }
        finally
        {
            // This block runs NO MATTER WHAT — success, failure, or return statement
            // Without this, a failed query would leave the connection open
            if (dbConnection != null && dbConnection.State == System.Data.ConnectionState.Open)
            {
                dbConnection.Close();
                Console.WriteLine("Database connection closed cleanly.");
            }
        }

        Console.WriteLine("Method finished.");
    }
}

Custom Exceptions and the 'throw' Keyword — Raising Meaningful Errors

Built-in exceptions like ArgumentNullException and InvalidOperationException are great for low-level problems, but they don't carry domain context. If your order processing system encounters an invalid coupon code, throwing a generic 'ArgumentException' with a message string isn't enough — the caller has no way to handle 'invalid coupon' differently from 'invalid email address' without parsing the message string, which is fragile and awful.

The solution is custom exceptions. You inherit from 'Exception' (or a more specific base like 'ApplicationException' — though most modern guidance says stick with Exception directly), add properties that carry domain-specific data, and throw it with a clear, structured payload. The caller can then catch your specific type and access those properties in a type-safe way.

The 'throw' keyword has two forms you need to know. 'throw new SomeException()' creates and throws a fresh exception. 'throw' on its own (inside a catch block) re-throws the current exception while preserving its original stack trace — this is critical. Using 'throw ex' instead of 'throw' resets the stack trace to the current line, destroying the diagnostic information that tells you where the problem actually started. This is one of the most common and damaging mistakes in C# exception handling.

using System;

// Custom exception that carries domain-specific diagnostic info
public class InvalidCouponException : Exception
{
    // The coupon code that caused the problem — type-safe, not buried in a message string
    public string AttemptedCouponCode { get; }
    public string CustomerId { get; }

    public InvalidCouponException(string couponCode, string customerId)
        : base($"Coupon '{couponCode}' is not valid for customer '{customerId}'")
    {
        AttemptedCouponCode = couponCode;
        CustomerId = customerId;
    }

    // Always provide this constructor — required for proper serialization across app domains
    public InvalidCouponException(string message, Exception innerException)
        : base(message, innerException) { }
}

class OrderProcessor
{
    static void ApplyDiscount(string customerId, string couponCode, decimal orderTotal)
    {
        // Simulate checking a database of valid coupons
        string[] validCoupons = { "SAVE10", "WELCOME20", "VIP50" };
        bool couponIsValid = Array.Exists(validCoupons, c => c == couponCode);

        if (!couponIsValid)
        {
            // Throw our custom exception with structured data the caller can use
            throw new InvalidCouponException(couponCode, customerId);
        }

        Console.WriteLine($"Discount applied! New total: {orderTotal * 0.9m:C}");
    }

    static void Main()
    {
        string customerId = "CUST-4821";
        string badCoupon = "FREESTUFF";

        try
        {
            ApplyDiscount(customerId, badCoupon, 150.00m);
        }
        catch (InvalidCouponException couponEx)
        {
            // We can access the structured properties — no string parsing needed
            Console.WriteLine($"[Order System] Coupon failed for customer {couponEx.CustomerId}");
            Console.WriteLine($"[Order System] Bad code attempted: '{couponEx.AttemptedCouponCode}'");
            Console.WriteLine("[Order System] Prompting user to re-enter coupon...");

            // Re-throw with 'throw' (not 'throw couponEx') to preserve the original stack trace
            // Uncomment the line below to see the difference in a real debugging session:
            // throw;
        }
        catch (Exception unexpectedEx)
        {
            // Wrapping an unexpected exception preserves the original as InnerException
            throw new Exception("Order processing failed unexpectedly", unexpectedEx);
        }
    }
}

Exception Filters and When Not to Catch — Advanced Real-World Patterns

C# 6 introduced exception filters with the 'when' keyword, and they're genuinely useful — not just a syntax novelty. They let you catch an exception only if a specific condition is true, without the exception being 'caught' in the traditional sense if the condition is false. This means the stack unwinds naturally to the next handler if your filter returns false, which is better for debugging than catching-then-rethrowing.

A classic use case: you only want to handle an HttpRequestException if the status code is a 429 (Too Many Requests), because that one is retryable. A 404 should bubble up differently. Without filters, you'd catch HttpRequestException, check the status, then either handle it or re-throw — re-throwing resets the stack trace. With a 'when' filter, the condition is evaluated before the catch activates, so no stack trace damage.

Equally important is knowing when to NOT catch exceptions. Catching an exception you can't meaningfully handle is worse than letting it propagate — you're hiding a bug. The rule of thumb senior devs use: only catch what you can recover from or what you need to translate into a better exception for the caller. Let everything else bubble up to a top-level handler (like ASP.NET's middleware) that logs it properly.

using System;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;

class HttpRetryExample
{
    static readonly HttpClient httpClient = new HttpClient();

    static async Task FetchUserDataAsync(int userId)
    {
        string apiUrl = $"https://api.example.com/users/{userId}";
        int maxRetries = 3;

        for (int attempt = 1; attempt <= maxRetries; attempt++)
        {
            try
            {
                Console.WriteLine($"Attempt {attempt}: Calling {apiUrl}");
                HttpResponseMessage response = await httpClient.GetAsync(apiUrl);

                // Throws HttpRequestException with StatusCode property if not successful
                response.EnsureSuccessStatusCode();

                string userJson = await response.Content.ReadAsStringAsync();
                Console.WriteLine($"Success: {userJson}");
                return; // Got what we needed — exit the retry loop
            }
            catch (HttpRequestException rateLimitEx)
                when (rateLimitEx.StatusCode == HttpStatusCode.TooManyRequests)
            {
                // Exception filter: this catch ONLY activates for 429 responses
                // The 'when' condition is checked BEFORE the catch block runs
                // Other HttpRequestExceptions (404, 500) will NOT be caught here
                Console.WriteLine($"Rate limited. Waiting before retry {attempt}...");
                await Task.Delay(TimeSpan.FromSeconds(Math.Pow(2, attempt))); // Exponential backoff
            }
            catch (HttpRequestException nonRetryableEx)
                when (nonRetryableEx.StatusCode == HttpStatusCode.NotFound)
            {
                // 404 is NOT retryable — wrap it and throw immediately
                // Using 'throw new' here because we're adding context, but preserving inner
                throw new InvalidOperationException(
                    $"User {userId} does not exist in the remote system.",
                    nonRetryableEx);
            }
            // Note: HttpRequestExceptions for 500 errors are NOT caught here
            // They propagate up to the caller — which is correct, we can't fix server errors
        }

        Console.WriteLine("Max retries exhausted. Request failed.");
    }

    static async Task Main()
    {
        try
        {
            await FetchUserDataAsync(userId: 42);
        }
        catch (InvalidOperationException domainEx)
        {
            Console.WriteLine($"[App] Business logic error: {domainEx.Message}");
        }
        catch (Exception unexpectedEx)
        {
            // Top-level catch — log it fully and fail gracefully
            Console.WriteLine($"[App] Unhandled error: {unexpectedEx.GetType().Name}: {unexpectedEx.Message}");
        }
    }
}

Global Exception Handling and Logging Patterns

Even with the best per-method exception handling, some exceptions will slip through. That's where global exception handlers come in. In a console application, you can subscribe to AppDomain.CurrentDomain.UnhandledException to catch all unhandled exceptions — but note that this handler cannot prevent the process from terminating. For ASP.NET Core applications, the UseExceptionHandler middleware provides a centralized way to log exceptions and return a friendly response to the client.

Structured logging is essential here. Instead of logging a plain message, use libraries like Serilog or NLog to capture exception details, stack traces, and correlation IDs. This turns a cryptic crash into a searchable, actionable log entry that your on-call team can actually use to diagnose the issue.

The pattern that senior developers follow is to have a single global handler that logs the exception with full context and then either re-throws (for console apps) or returns a 500 error (for APIs). Never try to resume the application after an unhandled exception — the state is corrupted. Instead, let it fail fast and restart via a process manager like Docker or supervisor.

Below is an example of a global exception handler in an ASP.NET Core application using Serilog. This handler logs the exception and returns a consistent error response without exposing internal details to the client.

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Http;
using Serilog;

public static class GlobalExceptionHandlerExtensions
{
    public static void UseGlobalExceptionHandler(this IApplicationBuilder app)
    {
        app.UseExceptionHandler(config =>
        {
            config.Run(async context =>
            {
                var exceptionFeature = context.Features.Get<IExceptionHandlerFeature>();
                if (exceptionFeature != null)
                {
                    var exception = exceptionFeature.Error;

                    // Structured logging with Serilog — captures full exception details
                    Log.Error(exception, "Unhandled exception occurred processing request {Method} {Path}",
                        context.Request.Method, context.Request.Path);

                    context.Response.StatusCode = 500;
                    context.Response.ContentType = "application/json";

                    // Return a safe error message (no stack trace exposed to client)
                    var response = new
                    {
                        error = "An unexpected error occurred. Please try again later.",
                        correlationId = context.TraceIdentifier
                    };

                    await context.Response.WriteAsJsonAsync(response);
                }
            });
        });
    }
}

// Startup.cs usage:
// public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
// {
//     app.UseGlobalExceptionHandler();
//     // ... other middleware
// }

Why You Should Never Catch System.Exception Without a Plan

I see this pattern in junior code all the time: a catch block swallowing Exception ex with a generic log message. That's not error handling—it's a cover-up. Catching the base Exception class is dangerous because it masks critical failures like OutOfMemoryException or StackOverflowException. These aren't recoverable; they signal a corrupted application state. The only time it's acceptable is when you rethrow immediately after logging, or you're at the top-level global handler where your sole job is to log details and shut down gracefully. In a catch block for Exception, always ask: "Can my program actually continue safely?" If the answer is unclear, log and throw. Microsoft's guidance is clear: never catch Exception unless you fully understand every exception subclass that could surface. Design your catches for specific exceptions—FileNotFoundException, InvalidOperationException—and let the rest propagate. Your operations team will thank you for not hiding bugs.

using System;

class Program
{
    static void Main()
    {
        try
        {
            ProcessFile("missing.txt");
        }
        catch (FileNotFoundException ex)
        {
            Console.WriteLine($"File not found: {ex.FileName}");
        }
        catch (Exception ex) // Only at top-level; rethrow
        {
            Console.WriteLine($"Critical: {ex.Message}");
            throw; // Preserve stack trace
        }
    }

    static void ProcessFile(string path)
    {
        System.IO.File.ReadAllText(path);
    }
}

The finally Block Is Your Safety Net for Resource Cleanup

Your database connections, file streams, network sockets—these are finite resources. When an exception blows a hole in your control flow, those resources leak unless you explicitly clean up. Enter finally. It runs unconditionally, even if the try block has a return statement or the catch block rethrows. I've seen teams debate whether to use finally versus a using statement for IDisposable objects. The answer: use using when possible—it's syntactic sugar for a try/finally that calls Dispose(). But when you're managing non-disposable resources (like manually releasing an unmanaged handle), finally is your only reliable mechanism. Don't put cleanup logic in the catch block—if no exception occurs, that block never runs. And don't put it after the try/catch structure—if the exception isn't caught, execution jumps past. finally is the only guarantee.

using System;
using System.IO;

class Program
{
    static void Main()
    {
        FileStream fs = null;
        try
        {
            fs = File.Open("data.bin", FileMode.Open);
            // Simulate a read failure
            throw new InvalidOperationException("Corrupt data");
        }
        catch (InvalidOperationException ex)
        {
            Console.WriteLine($"Handled: {ex.Message}");
        }
        finally
        {
            if (fs != null)
            {
                fs.Close();
                Console.WriteLine("File handle released.");
            }
        }
    }
}