C# Exceptions and Resource Cleanup: Handle Failure Without Hiding It

What you will understand

• Trace normal returns, thrown failures and matching catch blocks.
• Distinguish expected validation from a failed helper contract.
• Order specific handlers before their broader parent categories.
• Use finally for cleanup without implying success or rollback.
• Dispose owned resources with using on exception and return paths.
• Rethrow with throw; or preserve an inner cause when translating.
• Reject malformed file data without returning partial success.
• Test successful totals, meaningful failures and explicit disposal traces.

An exception is a failed operation, not an ordinary return value

A method normally returns a result and control continues after the call. If it throws an exception instead, it does not return that normal result. Execution leaves the failing statement and looks for an appropriate handler. Any remaining statements in that try block are skipped.

The first program deliberately parses invalid text. Before parse is printed, then int.Parse throws FormatException. The catch explains the failure and the program continues after the handled try/catch. It does not retry the parse, resume on the next line inside try or create a valid minutes value.

An exception object describes a failure category and may include diagnostic information such as a message, parameter name, cause and stack trace. The type is useful for choosing a handler. Avoid making logic depend on the exact wording of runtime-generated messages, which can vary by platform or localization.

A throw can happen several method calls below the code that initiated the work. Stack unwinding searches outward for a suitable catch and runs applicable cleanup along the way. An unhandled exception can terminate the process, so handle it where the program has enough context to make a meaningful decision.

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            Console.WriteLine("Before parse");
            int minutes = int.Parse("not-a-number");
            Console.WriteLine($"Parsed: {minutes}");
        }
        catch (FormatException)
        {
            Console.WriteLine("The text is not an integer");
        }
        Console.WriteLine("Caller continues");
    }
}

Select Run code to compile and execute this program.

Before parse
The text is not an integer
Caller continues

Use normal checks for expected input and exceptions for failed contracts

A person typing nonnumeric text in a form is an ordinary validation case. int.TryParse gives a Boolean result so the program can ask for a whole number without throwing for every mistake. Check that Boolean before treating the out value as valid data.

A helper can throw an argument exception when its caller violates a declared contract. DoubleMinutes accepts values from zero through six hundred and rejects values outside that range before calculating. It is the helper’s boundary; the caller decides whether it can correct the input or needs to stop that operation.

Expected does not mean impossible to represent as an exception. File APIs may throw for a missing file even when first-time absence is normal for your application. Choose how to interpret the failure at your application boundary instead of assuming every exception indicates a programming bug.

Do not use exceptions as a substitute for every if statement. Conversely, do not convert every failure into false or zero if that hides why the operation did not complete. The final file loader returns a total only when its complete read and validation succeed.

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        string input = "not-a-number";
        if (int.TryParse(input, out int minutes))
        {
            Console.WriteLine($"Minutes: {minutes}");
        }
        else
        {
            Console.WriteLine("Enter a whole number");
        }
    }
}

Select Run code to compile and execute this program.

Enter a whole number

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            Console.WriteLine(DoubleMinutes(-1));
        }
        catch (ArgumentOutOfRangeException error)
        {
            Console.WriteLine($"Rejected parameter: {error.ParamName}");
        }
    }

    static int DoubleMinutes(int minutes)
    {
        if (minutes < 0 || minutes > 600)
        {
            throw new ArgumentOutOfRangeException(nameof(minutes));
        }
        return minutes * 2;
    }
}

Select Run code to compile and execute this program.

Rejected parameter: minutes

Catch the failure you can explain or recover from

Put the smallest meaningful operation inside try, then catch categories that this layer can handle. A missing optional file may lead to a first-use message. A file containing invalid records should lead to a data problem, not be described as missing. A permission failure should not silently become an empty list.

Catch clauses are checked from specific to broad types. FileNotFoundException derives from IOException, so its special handler belongs before catch (IOException). Only the matching selected handler runs for that exception. The compiler refuses a later handler already covered by an earlier broader catch.

catch (Exception) at every helper is usually too broad: it can hide unrelated bugs and leave the caller with invented results. A top-level application may need a last-resort boundary for logging and a failed response, but that is different from claiming that a lower-level operation recovered successfully.

Catching an exception is not automatically recovery. Recovery means the program has an explicit valid next step, such as asking for corrected input or refusing to produce a report. If this layer cannot choose that step, let the failure propagate rather than concealing it.

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            throw new FileNotFoundException("Practice file missing.");
        }
        catch (FileNotFoundException)
        {
            Console.WriteLine("No saved file yet");
        }
        catch (IOException)
        {
            Console.WriteLine("Other file I/O failure");
        }
    }
}

Select Run code to compile and execute this program.

No saved file yet

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            throw new FileNotFoundException();
        }
        catch (IOException)
        {
            Console.WriteLine("I/O failure");
        }
        catch (FileNotFoundException)
        {
            Console.WriteLine("Missing file");
        }
    }
}

Select Run code to compile and execute this program.

Compilation fails: a previous catch already handles FileNotFoundException through IOException.

Finally is about cleanup, not success or rollback

A finally block runs when ordinary control leaves its protected try/catch, whether the operation succeeds, throws or returns. In the trace example, work fails, the catch handles it, and the finally message appears before execution continues.

Use finally for cleanup that belongs to this scope. Do not put a success message there: cleanup also runs on failure. Do not return or throw a new avoidable error from cleanup, because that can hide the original failure. Disposal itself can fail, so designs with important cleanup errors need deliberate diagnostic handling.

Finally is not a transaction. If the program wrote half a file before failure, finally does not restore the previous contents automatically. Likewise a catch does not undo messages already sent or records already saved. Atomic writes and transactions are separate design tools.

Cleanup guarantees describe ordinary runtime control flow, not every way a process can disappear. A forced process kill or machine failure can prevent cleanup code from executing. Prefer a clear scoped lifetime while recognizing that durable recovery needs more than a finally block.

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            Console.WriteLine("Work starts");
            throw new InvalidOperationException("Demonstration failure.");
        }
        catch (InvalidOperationException)
        {
            Console.WriteLine("Failure handled");
        }
        finally
        {
            Console.WriteLine("Cleanup step");
        }
        Console.WriteLine("After cleanup");
    }
}

Select Run code to compile and execute this program.

Work starts
Failure handled
Cleanup step
After cleanup

Use using for resources that your code owns

A StreamReader owns an underlying file handle, and a StreamWriter may buffer text before writing it. These resources should be disposed when their work ends. Garbage collection is not a prompt or predictable substitute for releasing such owned resources.

A using block makes that lifetime explicit with braces. A using declaration disposes the resource at the end of its enclosing scope. Both arrange cleanup when an exception leaves the scope or when a return exits it. Do not confuse these constructs with a using System directive, which simply brings names into scope.

TraceResource implements IDisposable only to make the cleanup call visible in output. The failure example prints Resource disposed before its outer catch handles the problem. The early-return example disposes before the caller receives the returned value. These deterministic traces teach the rule without depending on platform-specific file locking.

Only dispose what your code owns according to the API contract. A method that creates its own StreamReader normally owns it. A method handed a borrowed stream by its caller must not assume it can close that caller-owned resource. The final loader creates and owns its reader inside the method.

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            using (TraceResource resource = new TraceResource())
            {
                Console.WriteLine("Inside using");
                throw new InvalidDataException("Bad demonstration record.");
            }
        }
        catch (InvalidDataException)
        {
            Console.WriteLine("Caller handles bad data");
        }
    }
}

class TraceResource : IDisposable
{
    public void Dispose()
    {
        Console.WriteLine("Resource disposed");
    }
}

Select Run code to compile and execute this program.

Inside using
Resource disposed
Caller handles bad data

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        Console.WriteLine($"Result: {ReadFirst()}");
    }

    static int ReadFirst()
    {
        using TraceResource resource = new TraceResource();
        return 7;
    }
}

class TraceResource : IDisposable
{
    public void Dispose()
    {
        Console.WriteLine("Resource disposed");
    }
}

Select Run code to compile and execute this program.

Resource disposed
Result: 7

Rethrow without losing the original cause

If a catch adds useful local diagnostics but cannot recover, use throw; inside the catch to propagate the same exception. That preserves its original stack trace. Writing throw error restarts stack information at that rethrow point and makes the original failure harder to locate.

The Load example prints that invalid data was observed, then rethrows it. Main receives the same failure category. The local catch is included to demonstrate propagation; in a real system, omit it if it adds no useful context and let the exception travel naturally.

Sometimes a higher-level operation needs to translate the failure into its own vocabulary. The wrapper example throws InvalidOperationException with the original InvalidDataException supplied as the inner exception. This preserves a cause chain while intentionally changing the type callers must handle.

Do not wrap every failure just to change its message, and do not expose sensitive filesystem paths or credentials in user-facing diagnostics. Separate a clear user message from detailed diagnostic records. These examples print only fixed teaching text and stable category or parameter information.

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            Load();
        }
        catch (InvalidDataException error)
        {
            Console.WriteLine($"Caller received: {error.GetType().Name}");
        }
    }

    static void Load()
    {
        try
        {
            throw new InvalidDataException("Invalid minutes record.");
        }
        catch (InvalidDataException)
        {
            Console.WriteLine("Loader observed invalid data");
            throw;
        }
    }
}

Select Run code to compile and execute this program.

Loader observed invalid data
Caller received: InvalidDataException

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            LoadReport();
        }
        catch (InvalidOperationException error)
        {
            Console.WriteLine(error.Message);
            Console.WriteLine($"Cause: {error.InnerException?.GetType().Name}");
        }
    }

    static void LoadReport()
    {
        try
        {
            throw new InvalidDataException("Invalid record.");
        }
        catch (InvalidDataException error)
        {
            throw new InvalidOperationException("Cannot build the practice summary.", error);
        }
    }
}

Select Run code to compile and execute this program.

Cannot build the practice summary.
Cause: InvalidDataException

Define what a successful file load actually means

The lab file has one integer minute count per line. It accepts zero through six hundred per record and at most ten records. Empty files legitimately total zero, while blank lines, nonnumeric text, negative values and excessive values are invalid data. int.TryParse uses its ordinary integer syntax here, including outside whitespace; this is not a strict digits-only wire format.

The bound of ten records times six hundred minutes limits the total to six thousand. The loader can therefore use int addition without an unbounded accumulation policy. If the application removes those bounds, it must revisit arithmetic overflow and memory or processing limits instead of assuming the same implementation is safe for any input.

LoadMinutes returns only after the full file has been read and validated. A bad later line must not return a partial total as if it described the whole file. The exception includes a one-based line number so the caller can identify which record to correct.

Main distinguishes missing files, invalid data, I/O failures and denied access. The practice setup creates a known valid fixture; tests replace it with other cases. Files are confined to the temporary execution folder and discarded after each website run. A local console project can retain its own practice file across runs.

Test success, failure and cleanup as separate outcomes

A successful example is not enough. Test a valid minutes file, a genuinely empty one, a missing path, malformed first and later lines, negative or excessive values and more than ten records. Ensure failure does not print Total minutes or return a partial summary.

For cleanup, verify that leaving an owned using scope invokes disposal on normal completion, an exception and an early return. Do not use the ability to delete an open file as universal proof: operating-system sharing and deletion rules differ. The TraceResource examples make the cleanup event explicit.

The guided repair removes an empty catch that prints false success. The lab requires both a correct returned total and clear failure behavior. A test should check the message, whether a total was produced and which error category escaped, rather than accepting any exception as the expected one.

This completes the planned C# course sequence. Revisit the file lesson and build a small local reading-list or practice-log program: validate input, preserve object rules, save deliberately and explain each failure honestly. The course examples demonstrate these building blocks; they do not claim production persistence, concurrency control or a complete account-backed application.

Guided repair: stop reporting false success

The program catches an I/O failure and then prints Loaded successfully. Remove the false-success path and report that no summary was produced.

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            throw new IOException("Demonstration read failure.");
        }
        catch (IOException)
        {
        }
        Console.WriteLine("Loaded successfully");
    }
}

Select Run code to compile and execute this program.

Loaded successfully

Repair checkpoints

1. Identify the empty IOException catch as discarded failure information.
2. Choose an explicit failure outcome instead of pretending the load completed.
3. Keep success output only after real successful work.
4. Do not return zero or an empty list as a substitute for an unavailable file unless that is a stated valid policy.
5. Verify the demonstration prints only its clear failure message.

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        try
        {
            throw new IOException("Demonstration read failure.");
        }
        catch (IOException)
        {
            Console.WriteLine("Could not load the practice file; no summary produced");
        }
    }
}

Select Run code to compile and execute this program.

Could not load the practice file; no summary produced

Independent lab: load a complete valid minutes summary

Complete a bounded minutes-file loader. Read with an owned StreamReader, validate every record and return a total only after the whole input succeeds.

Acceptance checklist

• Create and own StreamReader with using inside LoadMinutes.
• Accept an empty file as total zero.
• Read up to ten lines, each parsed integer between zero and six hundred inclusive.
• Reject malformed, blank, negative or excessive records with InvalidDataException and a one-based line number.
• Reject an eleventh record rather than silently truncating the input.
• Return the sum only after full successful reading; do not return partial totals on failure.
• Let missing, permission and other file failures reach the caller’s appropriate handlers.
• Preserve Total minutes: 35 for the supplied 25, 10 and 0 fixture.

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        string folder = Path.Combine(Directory.GetCurrentDirectory(), "csharp-exception-practice");
        Directory.CreateDirectory(folder);
        string path = Path.Combine(folder, "minutes.txt");
        File.WriteAllLines(path, new[] { "25", "10", "0" }, Encoding.UTF8);
        try
        {
            int total = LoadMinutes(path);
            Console.WriteLine($"Total minutes: {total}");
        }
        catch (FileNotFoundException)
        {
            Console.WriteLine("No saved practice file yet");
        }
        catch (InvalidDataException error)
        {
            Console.WriteLine($"Cannot use this data: {error.Message}");
        }
        catch (IOException)
        {
            Console.WriteLine("Could not read the practice file");
        }
        catch (UnauthorizedAccessException)
        {
            Console.WriteLine("Permission is required to read the practice file");
        }
    }

    static int LoadMinutes(string path)
    {
        // TODO: own the reader with using; validate up to 10 lines, then return the total.
        return 0;
    }
}

Select Run code to compile and execute this program.

Total minutes: 0

using System;
using System.IO;
using System.Text;

class Program
{
    static void Main()
    {
        string folder = Path.Combine(Directory.GetCurrentDirectory(), "csharp-exception-practice");
        Directory.CreateDirectory(folder);
        string path = Path.Combine(folder, "minutes.txt");
        File.WriteAllLines(path, new[] { "25", "10", "0" }, Encoding.UTF8);
        try
        {
            int total = LoadMinutes(path);
            Console.WriteLine($"Total minutes: {total}");
        }
        catch (FileNotFoundException)
        {
            Console.WriteLine("No saved practice file yet");
        }
        catch (InvalidDataException error)
        {
            Console.WriteLine($"Cannot use this data: {error.Message}");
        }
        catch (IOException)
        {
            Console.WriteLine("Could not read the practice file");
        }
        catch (UnauthorizedAccessException)
        {
            Console.WriteLine("Permission is required to read the practice file");
        }
    }

    static int LoadMinutes(string path)
    {
        int total = 0;
        int lineNumber = 0;
        using StreamReader reader = new StreamReader(path, Encoding.UTF8);
        string? line;
        while ((line = reader.ReadLine()) is not null)
        {
            lineNumber++;
            if (lineNumber > 10)
            {
                throw new InvalidDataException("At most 10 records are allowed.");
            }
            if (!int.TryParse(line, out int minutes) || minutes < 0 || minutes > 600)
            {
                throw new InvalidDataException($"Invalid minutes on line {lineNumber}.");
            }
            total += minutes;
        }
        return total;
    }
}

Select Run code to compile and execute this program.

Total minutes: 35

Changed-input checks

• An empty file totals 0; 0 and 600 are accepted boundary records.
• A malformed second line identifies line 2 and returns no partial total.
• Blank, -1 and 601 records are rejected as invalid data.
• Eleven otherwise valid records are refused.
• A missing file reaches the missing-file message.
• The owned reader is disposed on both successful and exceptional exits.

Recap: failure policy and resource ownership

Identify the valid result, the failure category, the layer that can recover and the scope that owns cleanup.

try

Protect a focused operation that may throw.

catch (SpecificException)

Handle a category when this layer can choose a meaningful next step.

finally

Perform cleanup during ordinary scope exit, not automatic rollback.

TryParse

Represent expected invalid text with a checked Boolean result.

throw new ...

Signal a failed contract with an appropriate exception type.

throw;

Propagate the current caught exception while preserving its original stack.

InnerException

Retain the original cause when deliberately translating a failure.

using

Dispose an owned resource at block or scope exit.

Frequently asked questions

Course practice and references

A catch needs a meaningful failure policy, and a resource needs a clear owner. Validate expected input, let failures reach a suitable boundary, preserve causes and use scoped disposal instead of hiding problems.

You have reached the final lesson in the planned C# curriculum. Practice by building a small local reading-list or minutes-log program, combining validated input, clear object contracts, deliberate file writes and honest failure handling.

Official references

Original SovranCode explanations, examples and exercises. Technical details were checked against these references.

• Microsoft Learn: Exceptions and exception handling
• Microsoft Learn: using and deterministic disposal

Last updated: 27 October 2026.