Exceptions

When things go wrong

Files go missing, networks drop, users type "abc" where a number belongs. When code hits a situation it can't handle, .NET throws an exception: it stops executing the current code and travels back up the call stack looking for someone who can catch it. If nobody does, the program crashes with the message and stack trace you learned to read in Reading errors and debugging.

try / catch

Wrap code that might fail in try, and handle failures in catch:

try
{
    string text = File.ReadAllText("settings.json");
    Console.WriteLine($"Loaded {text.Length} characters");
}
catch (FileNotFoundException)
{
    Console.WriteLine("No settings file — using defaults");
}
catch (UnauthorizedAccessException ex)
{
    Console.WriteLine($"Permission denied: {ex.Message}");
}

• As soon as an exception is thrown in try, the rest of the try block is skipped.
• C# checks the catch blocks in order and runs the first one whose type matches.
• Put specific exception types before general ones like Exception.
• ex gives you the exception object: ex.Message, ex.StackTrace, ex.InnerException.

finally: cleanup that always runs

var connection = OpenConnection();
try
{
    connection.Send(data);
}
finally
{
    connection.Close();     // runs whether Send succeeded, threw, or returned
}

In practice, the using statement (Track 5) writes this try/finally for you.

Exception filters

Catch only when a condition holds:

catch (HttpRequestException ex) when (ex.StatusCode == HttpStatusCode.NotFound)
{
    Console.WriteLine("Not found");
}

Throwing exceptions

Your own methods should throw when they're called incorrectly — fail fast instead of continuing with bad data:

void SetAge(int age)
{
    if (age < 0 || age > 150)
        throw new ArgumentOutOfRangeException(nameof(age), age, "Age must be 0–150");
    ...
}
 
void Register(string email)
{
    ArgumentException.ThrowIfNullOrWhiteSpace(email);   // built-in guard helper
    ...
}

Use the right built-in type:

nameof(age) produces the string "age", and keeps working if you rename the parameter.

Rethrowing

Sometimes you want to log an exception and let it continue upward:

catch (Exception ex)
{
    logger.LogError(ex, "Import failed");
    throw;               // ✅ rethrows, keeping the original stack trace
    // throw ex;         // ❌ resets the stack trace to this line
}

Custom exceptions

When callers need to react to a specific domain problem, define your own type:

class InsufficientFundsException : Exception
{
    public decimal Shortfall { get; }
 
    public InsufficientFundsException(decimal shortfall)
        : base($"Insufficient funds: {shortfall:F2} short")
    {
        Shortfall = shortfall;
    }
}

By convention, the name ends with Exception.

Exceptions are for exceptional situations

Throwing is relatively expensive and makes control flow harder to follow. For expected outcomes, return a result instead:

// ❌ using exceptions for normal flow
try { var n = int.Parse(input); } catch (FormatException) { ... }
 
// ✅ the Try pattern
if (int.TryParse(input, out var n)) { ... } else { ... }

Try it

Key takeaways

• try/catch handles exceptions; specific catch blocks go first; finally always runs.
• Throw ArgumentException and friends to reject invalid input early — use nameof.
• Rethrow with throw;, never throw ex;.
• Don't use exceptions for expected outcomes, and never swallow them silently.