C# Control Flow — The Loop Exit Patterns That Prevent Hangs

try-finally is the lower-level construct that executes the finally block regardless of whether an exception occurred. It's used when you need more flexibility than using provides, e.g., when you need to close multiple resources or perform cleanup that isn't a simple Dispose call.

A production gotcha: finally blocks are not guaranteed to run if the process is killed (e.g., via Environment.FailFast or out-of-process kill). For critical cleanup like releasing a distributed lock, use a timeout-based or compensation pattern.

using System;
using System.IO;

namespace io.thecodeforge.flow
{
    public class ResourceManagement
    {
        public static void Main()
        {
            // using declaration (C# 8.0+) – disposes at end of scope
            using var reader = new StreamReader("config.json");
            string content = reader.ReadToEnd();
            Console.WriteLine("File content read. Disposed when variable goes out of scope.");

            // try-finally for non-disposable cleanup
            bool lockAcquired = false;
            try
            {
                lockAcquired = AcquireDistributedLock("payment-lock");
                ProcessPayment();
            }
            finally
            {
                if (lockAcquired)
                {
                    ReleaseDistributedLock("payment-lock");
                }
            }
        }

        static bool AcquireDistributedLock(string name) => true;
        static void ReleaseDistributedLock(string name) { }
        static void ProcessPayment() { }
    }
}

Branches and Loops: The Difference Between Correct and Correct Enough

Most tutorials teach you if and for in isolation. They treat them like magic spells: say the words and the machine obeys. That's how you end up with 150-line switch statements that make code reviews last three hours.

The real question isn't "how do I write a branch?" It's "when does a branch become a liability?" Every conditional adds a path through your code. Every loop multiplies that path by its iterations. A function with three nested if statements inside a while loop has more possible states than you can test manually.

Your job isn't to write correct branches. It's to write branches that stay correct when the data changes. That means: - Prefer early returns over nested if blocks. - Use foreach unless you need an index — it eliminates off-by-one errors. - Keep loop bodies under 15 lines. If you're scrolling, extract a method. - When you write an else, ask: "Is this hiding an edge case?"

The difference between a junior and a senior isn't knowing the syntax. It's knowing when to avoid it.

// io.thecodeforge — csharp tutorial

public class OrderProcessor
{
    private readonly IDiscountService _discounts;

    public OrderProcessor(IDiscountService discounts)
    {
        _discounts = discounts;
    }

    public decimal CalculateTotal(Order order)
    {
        if (order == null)
            throw new ArgumentNullException(nameof(order));

        if (!order.Items.Any())
            return 0m;

        decimal subtotal = 0;
        foreach (var item in order.Items)
        {
            subtotal += item.Price * item.Quantity;
            
            // Max 15 lines per loop body -- extract if needed
            if (item.IsOnPromotion)
                subtotal -= _discounts.ApplyPromotion(item);
        }

        return subtotal + order.ShippingCost;
    }
}

Tuples and Types: Stop Passing Anonymous Objects Like a Cowboy

You've seen it. A method returns object. The caller casts it. Somewhere in the middle of a 400-line controller, someone adds a new field. Boom. Runtime exception. The compiler knew the type all along — you just didn't tell it.

Tuples are the middle ground between anonymous objects and full-blown DTOs. They're fine for internal methods where the consumer is within the same file. They're a disaster in public APIs because the field names don't survive decompilation. Item1, Item2 — that's the language of the damned.

If a tuple escapes a single method, refactor it into a record. Why? Because records give you: - Compile-time type safety - Structural equality for free - A clear contract in the signature - Proper deserialization with JSON/System.Text.Json

The rule is simple: tuples for internal plumbing, records for public contracts, and never dynamic unless you're talking to COM or a JSON blob from 2008.

Your types are your documentation. If the type doesn't tell me what it holds, you're making me read the implementation. Don't make me read the implementation.

// io.thecodeforge — csharp tutorial

public record SalesReport(
    string Region,
    decimal Revenue,
    int UnitsSold,
    DateTime PeriodStart
);

public class ReportGenerator
{
    public List<SalesReport> GenerateReports(DateTime period)
    {
        var raw = FetchSalesFromDb(period);
        
        return raw.Select(row => new SalesReport(
            row.Region,
            row.Revenue,
            row.UnitsSold,
            period
        )).ToList();
    }
    
    // Internal helper -- tuple is fine here
    private (decimal Total, int Count) CalculateAggregate(List<SalesReport> reports)
    {
        var total = reports.Sum(r => r.Revenue);
        return (total, reports.Count);
    }
}

What's Next? The 20% of C# That Causes 80% of Production Issues

You've mastered branches, loops, and basic types. Congratulations — you're now dangerous. The next layer is where real production fires start: threading, memory management, and async.

Most devs think they understand Task and await. Then a deadlock happens in production because they mixed synchronous blocking with async code. Or memory spikes because they captured large objects in closures inside loops. Or race conditions because they forgot that List<T> isn't thread-safe.

Don't just Google these. Reproduce the failures in a test project. Break things deliberately. That's how you learn what your compiler is actually doing.

The next incident you prevent won't be from knowing more syntax. It'll be from understanding where your code breaks.

// io.thecodeforge — csharp tutorial

public class DeadlockExample
{
    private static readonly HttpClient _client = new();

    // THIS CAUSES A DEADLOCK -- never block on async
    public string GetDataWrong()
    {
        return _client.GetStringAsync("https://api.example.com/data").Result;
    }

    // THIS IS CORRECT -- always async all the way
    public async Task<string> GetDataCorrect()
    {
        return await _client.GetStringAsync("https://api.example.com/data")
                           .ConfigureAwait(false);
    }
}

Numbers Lie: Why int, float, and decimal Crash Differently

Production systems don't crash on syntax errors. They crash because you picked the wrong number type. int overflows silently. float loses precision after a few million operations. decimal is slow but honest.

When you check if a float equals 0.1, you're checking against 0.100000001490116. That's not your fault. It's IEEE 754. The fix is simple: never compare floats with ==. Use an epsilon threshold. Or better, use decimal for money, int for counts, and double only when you've measured the error.

Your loop that counts to a billion using float will never terminate. The increment gets too small to change the accumulator. That's not a bug in the loop — it's a bug in the type. Stop blaming control flow when the real problem is the data type sitting inside it.

// io.thecodeforge — csharp tutorial

using System;

float accumulator = 0.0f;
for (int i = 0; i < 100; i++)
{
    accumulator += 0.1f;
}

Console.WriteLine($"Expected 10, got {accumulator}");
Console.WriteLine($"Check: {accumulator == 10.0f}"); // false

Hello World Is a Deployment: Why Main() Is the Last Place You Debug

You wrote your first program and it printed "Hello World". Cute. Now ask yourself: what happens when that Console.WriteLine throws because stdout is redirected to a broken pipe? Your app crashes silently in production. That's not theory. That's Monday morning.

Control flow starts before your first line of code runs. The runtime initializes static fields, calls static constructors, and checks assembly dependencies. A missing reference kills your app before Main() even sees the CPU. That's why you wrap top-level statements in try-catch. That's why you log startup failures to EventLog, not just the console.

Hello World is the simplest possible path. Real code has environment checks, config validation, and health probes. Treat Main() as a controlled detonation, not a tutorial demo. If your app can't print "Hello" without crashing, the loop logic you wrote doesn't matter.

// io.thecodeforge — csharp tutorial

using System;

try
{
    Console.WriteLine("Hello, World");
    // Your real init here
}
catch (Exception ex)
{
    Console.Error.WriteLine($"Startup failed: {ex.Message}");
    Environment.Exit(1);
}

do-while: The Loop That Runs Before It Thinks

Most loops check the condition before executing. do-while flips that: it runs the body once, then checks the condition. This matters when you need guaranteed first-run behavior—for example, reading user input until they enter a valid value. The difference between while and do-while is not cosmetic; it's a structural guarantee. If your first iteration must happen regardless of initial state, do-while is the correct choice. Overusing while and prepending manual setup code is a common source of duplication and off-by-one errors. Use do-anytime the loop body's side effect is required to produce the condition's input. Production trap: many developers default to while, then work around its first-check behavior with a boolean flag. That flag is a code smell—it signals you should have used do-while.

// io.thecodeforge — csharp tutorial

int value;
do {
    Console.Write("Enter a positive number: ");
    string? input = Console.ReadLine();
    int.TryParse(input, out value);
} while (value <= 0);

Console.WriteLine($"You entered {value}");

Consecutive Sums: When Correct Math Beats Clever Code

Consecutive sums—adding numbers from A to B without a loop—is a pattern that exposes the gap between brute-force thinking and arithmetic reasoning. The naive approach uses a for-loop accumulating integer by integer. The production-ready approach uses the arithmetic series formula: sum = (A + B) * (count) / 2, where count = B - A + 1. The first version is O(n) and fails under large ranges with integer overflow. The second is O(1) and forces you to think about division order to avoid truncation errors. In C#, integer division loses the fraction; you must ensure the product is even before dividing, or use long and divide at the end. This tiny pattern repeats everywhere: building cumulative metrics, pagination offsets, and time-series aggregates. Getting it wrong silently corrupts reports.

// io.thecodeforge — csharp tutorial

int a = 1, b = 100;
long count = b - a + 1;
long sum = (a + b) * count / 2;

Console.WriteLine(sum);