Exception Handling in C#: Writing Code That Fails Gracefully

From Runtime Crashes to Resilient Software — What Exceptions Are, How to Catch Them, and Why Getting This Right Separates Beginner Code from Production-Ready Software

Every program, no matter how carefully written, will eventually encounter something unexpected: a file that does not exist, a user who types letters where a number was expected, a network connection that drops mid-request. The question is never whether your code will fail — it is what happens when it does. Programs that crash abruptly and leave users staring at a cryptic error message are not just frustrating; they are fragile by design. Programs that anticipate failure, respond to it gracefully, and communicate it clearly are the foundation of professional software.

This article walks you through exception handling in C# from the ground up. You will learn what an exception is and how the .NET runtime represents it, how to navigate the exception class hierarchy, and how to catch and throw exceptions using try, catch, finally, and throw. You will also learn how to define your own exception types and how all of these tools come together in realistic code. By the end, you will not just know the syntax — you will understand the intent behind it.

What Is an Exception?

In C#, an exception is a runtime event that signals something went wrong during the execution of a program — something that the normal flow of code cannot handle on its own. This is an important distinction: exceptions are not compile-time errors, the kind your IDE catches before you even run your program. They are conditions that emerge while the program is actually running, often because the world outside your code did not behave as expected.

When an exception occurs, C# represents it as an object — specifically, an instance of a class that derives from System.Exception. This object carries information about what went wrong: a human-readable message, a snapshot of where in the code the failure occurred, and sometimes a reference to another exception that caused it. Something in your code — or in the .NET runtime itself — throws this object, and some other part of your code is expected to catch it and decide what to do next.

If nothing catches the exception, it propagates up through the call stack — the chain of method calls that led to the point of failure — until it reaches the top. If it makes it all the way there without being caught, the program crashes and the .NET runtime displays an unhandled exception message. Understanding this bubbling behavior is fundamental, because it explains both why exception handling is necessary and where in your code it should live.

The Exception Class Hierarchy

All exceptions in C# ultimately derive from System.Exception, the base class that every exception object is an instance of, or a subclass of. This class exposes several properties that you will use constantly when working with exceptions. Message is a human-readable string describing what went wrong. StackTrace is a string representation of the call stack at the moment the exception was thrown — invaluable when debugging. InnerException is a reference to another exception that was the underlying cause of this one, useful when you wrap one exception inside another to add context.

Historically, .NET distinguished between SystemException — thrown by the runtime itself for errors like accessing a null reference or stepping outside the bounds of an array — and ApplicationException, intended for exceptions raised by application-level code. In practice, this distinction is rarely meaningful today. Modern .NET guidance recommends deriving your own exception types directly from Exception, regardless of whether you are writing library code or application code.

What is worth knowing are the exceptions you will encounter most often as a beginner. NullReferenceException is thrown when you attempt to access a member on an object reference that holds null. IndexOutOfRangeException appears when you access an array at an index that does not exist. InvalidOperationException signals that a method call is not valid given the current state of an object. ArgumentException and its subclass ArgumentNullException are thrown when a method receives an argument that is illegal or missing. FormatException arises when you try to parse a string into a number or date and the format is not what was expected. These five account for a significant portion of the exceptions you will see while learning C#, and recognizing them on sight will save you a great deal of debugging time.

Catching Exceptions: try, catch, and finally

The mechanism for intercepting exceptions in C# is the try/catch block. Code that might throw an exception goes inside a try block. If an exception is thrown anywhere within that block, execution immediately jumps to the corresponding catch block, where you handle the failure. Consider a concrete, everyday example: parsing a number from user input.

Console.Write("Enter a number: ");
string input = Console.ReadLine();

try
{
    int number = int.Parse(input);
    Console.WriteLine($"You entered: {number}");
}
catch (FormatException ex)
{
    Console.WriteLine($"That wasn't a valid number. Details: {ex.Message}");
}

int.Parse will throw a FormatException if the user types something that cannot be converted to an integer. Without the try/catch, that exception would propagate up and crash the program. With it, control flows to the catch block, the error is communicated clearly to the user, and execution continues normally afterward. Notice that the catch clause names the exception type it handles — FormatException — and binds the exception object to the variable ex, giving you access to its properties inside the block.

Alongside try and catch, C# provides a finally block — one that executes unconditionally, regardless of whether an exception was thrown or caught. This is critical for cleanup work: releasing file handles, closing database connections, or freeing any resource that must be released even if something went wrong mid-operation.

StreamReader reader = null;

try
{
    reader = new StreamReader("config.txt");
    string content = reader.ReadToEnd();
    Console.WriteLine(content);
}
catch (FileNotFoundException ex)
{
    Console.WriteLine($"File not found: {ex.Message}");
}
finally
{
    reader?.Close(); // Runs whether or not an exception occurred
}

The finally block here guarantees that the file handle is closed no matter what happens inside try. Even if an exception is thrown and not caught — even if it propagates further up the call stack — the finally block will still execute before that propagation continues. This makes finally the right place for any logic that must run to maintain a stable, clean state.

Catching Specific vs. General Exceptions

A single try block can have multiple catch clauses, each targeting a different exception type. C# evaluates them in order from top to bottom and executes the first one whose type matches the thrown exception. This ordering matters: more specific exception types must appear before more general ones, or the compiler will warn you that the specific clauses can never be reached.

try
{
    string text = File.ReadAllText(filePath);
    int value = int.Parse(text.Trim());
    Console.WriteLine($"Parsed value: {value}");
}
catch (FileNotFoundException ex)
{
    Console.WriteLine($"The file does not exist: {ex.Message}");
}
catch (FormatException ex)
{
    Console.WriteLine($"The file contents could not be parsed as a number: {ex.Message}");
}
catch (Exception ex)
{
    Console.WriteLine($"An unexpected error occurred: {ex.Message}");
}

C# also provides the when keyword, which lets you attach a conditional filter to a catch clause. The clause is only entered if both the exception type matches and the condition evaluates to true. This is useful when the same exception type can carry different meanings depending on context.

catch (IOException ex) when (ex.Message.Contains("disk full"))
{
    Console.WriteLine("The disk is full. Please free some space and try again.");
}

One of the most common mistakes beginners make is writing a blanket catch (Exception ex) as their only catch clause, with the intention of handling everything at once. While this compiles and runs, it almost always obscures the real problem. It treats every failure identically, swallows errors that deserve different responses, and makes it nearly impossible to diagnose what actually went wrong. Reserve the general Exception catch as a last resort or a logging boundary, and always prefer catching the most specific type you can anticipate.

Throwing Exceptions

Catching exceptions is only half the story. Your code will also need to throw them — deliberately raising an exception when it detects a condition that should not be allowed to continue. The most common scenario is validating method arguments before proceeding with an operation.

public void SetAge(int age)
{
    if (age < 0 || age > 150)
    {
        throw new ArgumentOutOfRangeException(nameof(age), "Age must be between 0 and 150.");
    }

    _age = age;
}

Using nameof(age) here is a subtle but important habit. It passes the parameter name as a string without hardcoding it, so if the parameter is renamed during a refactor, the exception message updates automatically. Small details like this are what separate code written for now from code written to last.

When re-throwing a caught exception, C# gives you two options, and the difference between them is significant for debugging. A bare throw statement — with no argument — re-throws the current exception while preserving its original stack trace. Writing throw ex instead re-throws it but resets the stack trace to the current location, erasing information about where the problem originated. Since the original stack trace is often the fastest path to understanding a bug, bare throw is almost always the right choice.

catch (IOException ex)
{
    Log(ex);  // Record what happened
    throw;    // Re-throw with the original stack trace intact
}

When the context has genuinely changed — for instance, when a low-level I/O failure occurs inside a higher-level operation — a better pattern is to wrap the original exception in a new, more descriptive one and pass it as the InnerException. This way, callers receive meaningful context about what operation failed, while the underlying cause is preserved and accessible.

catch (IOException ex)
{
    throw new ApplicationException("Failed to load user configuration.", ex);
}

Defining Custom Exceptions

The built-in exceptions cover a wide range of failure conditions, but they are, by necessity, generic. When you are building a domain-specific system — a reservation platform, a billing engine, or a file processing pipeline — an InvalidOperationException tells a caller very little about what actually went wrong and why. A ReservationConflictException or InsufficientFundsException, on the other hand, is self-documenting and makes the intent of your code immediately clear.

Creating a custom exception in C# is straightforward: define a class that inherits from Exception and follows the *Exception naming convention. By convention, you should also include three standard constructors that mirror the signatures found on the base class.

public class ReservationConflictException : Exception
{
    public ReservationConflictException()
        : base("A conflicting reservation already exists for this time slot.") { }

    public ReservationConflictException(string message)
        : base(message) { }

    public ReservationConflictException(string message, Exception innerException)
        : base(message, innerException) { }
}

This three-constructor pattern ensures your custom exception behaves consistently with the rest of the .NET ecosystem. Any caller who catches Exception as a base type will still catch yours, and anyone who wants to handle it specifically can target ReservationConflictException by name. You can extend this further by adding custom properties — such as the ID of the conflicting reservation — to carry domain-specific detail that makes error reporting richer and more actionable.

Exception Handling in the Real World

To see these pieces work together, consider a realistic scenario: loading application settings from a configuration file, parsing them, and returning a structured result to the caller. This is the kind of code that appears in almost every non-trivial application, and it touches nearly every concept covered so far.

public AppConfig LoadConfig(string filePath)
{
    StreamReader reader = null;

    try
    {
        reader = new StreamReader(filePath);
        string json = reader.ReadToEnd();
        return ParseConfig(json);
    }
    catch (FileNotFoundException ex)
    {
        throw new ApplicationException($"Configuration file not found at: {filePath}", ex);
    }
    catch (FormatException ex)
    {
        throw new ApplicationException("Configuration file is malformed and could not be parsed.", ex);
    }
    finally
    {
        reader?.Close();
    }
}

This method catches the exceptions it knows how to contextualize, wraps each in a more descriptive ApplicationException with the original exception preserved as InnerException, and guarantees the file reader is closed in finally no matter what. Building on this understanding of finally, C# provides the using statement as a cleaner, more idiomatic alternative for managing resources that implement IDisposable. A using block guarantees that Dispose is called at the end of the block — semantically equivalent to a try/finally with a Close call, but without the boilerplate.

public AppConfig LoadConfig(string filePath)
{
    try
    {
        using (var reader = new StreamReader(filePath))
        {
            string json = reader.ReadToEnd();
            return ParseConfig(json);
        }
    }
    catch (FileNotFoundException ex)
    {
        throw new ApplicationException($"Configuration file not found at: {filePath}", ex);
    }
    catch (FormatException ex)
    {
        throw new ApplicationException("Configuration file is malformed and could not be parsed.", ex);
    }
}

One principle that applies across all of these patterns: exceptions should be exceptional. They are not a substitute for ordinary conditional logic. If you are checking whether a dictionary contains a key, use TryGetValue — not a try/catch around an access that throws KeyNotFoundException. Exceptions carry overhead, and more importantly, they signal that something unexpected happened. Using them for foreseeable, routine conditions obscures the intent of your code and makes it harder for anyone — including your future self — to reason about.

From Crashes to Confidence: Closing Thoughts on Exception Handling

Exception handling is one of those topics that looks deceptively simple on the surface: wrap some code in try/catch, done. But the craft is in the details — which exceptions to catch and where, how to preserve context when rethrowing, when to define custom types, and when to let an exception propagate rather than swallowing it silently. The mental model to carry forward is this: an exception is an object, thrown at runtime by either your code or the .NET runtime, caught by a matching handler, and propagated up the call stack if no handler is found. Every feature covered in this article — finally, when, throw, InnerException, custom exception classes — is a tool for giving that propagation meaning and direction.

The shift from beginner to professional code often reveals itself most clearly in how errors are handled. Beginner code either ignores exceptions entirely or catches everything indiscriminately. Professional code is deliberate: it catches specific exceptions where it can respond meaningfully, preserves context when rethrowing, and surfaces failures to the caller with enough information to act on them. That intentionality is not a matter of knowing more syntax — it is a matter of thinking carefully about your code’s responsibilities and its relationship with the code that calls it.