Exceptions, and catching the type you actually expect

try
{
    var result = Divide(a, b);
    Console.WriteLine(result);
}
catch (DivideByZeroException e)
{
    Console.WriteLine($"cannot divide: {e.Message}");
}
finally
{
    Console.WriteLine("always runs");
}

finally runs whether try succeeded, threw an exception that was caught, or threw one that was not — even after a return inside try. It is where cleanup belongs when the type itself is not IDisposable and using does not apply.

A catch clause with no type — catch { ... } — catches everything, including exceptions the code has no idea how to handle correctly. An empty catch block is worse than no catch at all: the program continues as if nothing happened, with whatever caused the exception now silently unaddressed, and no trace of it anywhere.

Try it

1public static class Solution2{3    public static string Describe()4    {5        try6        {7            int[] nums = { 1, 2, 3 };8            return "value=" + nums[5];9        }10        catch (IndexOutOfRangeException e)11        {12            return "index: " + e.GetType().Name;13        }14        catch (Exception e)15        {16            return "generic: " + e.GetType().Name;17        }18    }19}

Catch the most specific type first

try { Process(data); }
catch (FileNotFoundException e) { /* a subclass of IOException */ }
catch (IOException e)            { /* the broader type */ }

C# checks catch clauses top to bottom and runs the first one whose type the thrown exception matches. Putting IOException first would catch everything below it too, and the compiler refuses to compile an unreachable catch clause that follows — the ordering is enforced, not just good style.

Custom exceptions

public class InsufficientFundsException : Exception
{
    public decimal Needed { get; }
    public decimal Available { get; }

    public InsufficientFundsException(decimal needed, decimal available)
        : base($"needed {needed}, had {available}")
    {
        Needed = needed;
        Available = available;
    }
}

A custom exception is a real class, usually with almost no logic in it — its job is to give a catch clause something specific to match, and to carry whatever data the caller needs to react correctly, rather than parsing that information back out of a generic message string.

Let what you cannot handle travel on

Catching is a promise that this code knows what to do about the failure. When it does not, the right move is to let the exception reach a caller that does, either by not catching it at all or by rethrowing. How you rethrow matters:

1using System.Diagnostics;2using System.Runtime.CompilerServices;3 4public static class Solution5{6    [MethodImpl(MethodImplOptions.NoInlining)]7    static void Inner() => throw new InvalidOperationException("boom");8 9    [MethodImpl(MethodImplOptions.NoInlining)]10    static void RethrowBare()11    {12        try { Inner(); }13        catch (InvalidOperationException) { throw; }14    }15 16    [MethodImpl(MethodImplOptions.NoInlining)]17    static void RethrowVariable()18    {19        try { Inner(); }20        catch (InvalidOperationException e) { throw e; }21    }22 23    // The method at the top of the exception's stack trace.24    static string TopFrame(Action action)25    {26        try { action(); return "none"; }27        catch (Exception e) { return new StackTrace(e).GetFrame(0)!.GetMethod()!.Name; }28    }29 30    public static string Describe() =>31        $"throw; -> {TopFrame(RethrowBare)} | throw e; -> {TopFrame(RethrowVariable)}";32}

throw; rethrows the exception that is being handled with its stack trace intact, so the trace still starts at Inner, where the failure happened. throw e; throws the same object as if it were new, and the trace now starts at the catch block: the line that actually failed is gone from the log.

Common mistakes

• catch (Exception) around code that can fail in more than one way. A dictionary's indexer throws KeyNotFoundException for an absent key but ArgumentNullException for a null key: the first is ordinary missing data, the second is a bug in whoever built the request. A broad catch files both under the same heading. The exercise below is built to notice.
• throw e; instead of throw;. Shown above: the original stack trace is replaced. To add context, wrap instead: throw new ImportException("row 7", e); keeps the original as InnerException.
• An empty catch block. The program carries on in a state nobody checked, and nothing is logged.
• Exceptions for expected outcomes. If bad input is normal, test for it (TryGetValue, int.TryParse) rather than paying for a throw on every bad row.