How do block scope and reachability interact with Java's definite-assignment rule for local variables?

## Local variables have no default value Instance and static **fields** are automatically initialized to a default (0, false, null). **Local variables are not.** A local has an undefined value until you assign one, so Java protects you with the **definite-assignment** rule: the compiler must be able to prove that on *every* path that reaches a *read* of a local, the local has *definitely been assigned* first. If it can't, compilation fails with 'variable might not have been initialized'. ```java int x; System.out.println(x); // ERROR: x might not have been initialized ``` ## Why this is a flow analysis, not just a syntax check The compiler performs a conservative **data-flow analysis** over the control-flow graph of the method. At each point it tracks the set of locals that are *definitely assigned*. A read is legal only if the variable is in that set on all incoming paths. ## Interaction with block scope Where you **declare** the variable (which block) sets its visibility; where you **assign** it determines definite assignment. A frequent, idiomatic pattern: declare in an outer block, assign in each branch: ```java int result; // declared, not assigned if (cond) { result = 1; // assigned on this path } else { result = 2; // assigned on that path } System.out.println(result); // OK: every path assigned it ``` If you drop the `else` and there's no other assignment, the read fails — one path leaves `result` unassigned: ```java int result; if (cond) { result = 1; } System.out.println(result); // ERROR: not assigned when cond is false ``` If instead you declared `result` *inside* the `if` block, it wouldn't even be in scope after the block, so the problem becomes a scope error rather than a definite-assignment one. The two rules work together. ## Reachability lets some branches off the hook The analysis also tracks **reachability**. If a branch cannot fall through to the read — because it `return`s, `throw`s, `break`s, or `continue`s — that path imposes no assignment obligation: ```java int result; if (cond) { result = 1; } else { throw new IllegalStateException(); // this path never reaches the read } System.out.println(result); // OK: the only surviving path assigned result ``` Similarly a `switch` that assigns in every case and has a `default` (or is exhaustive) satisfies the rule. ## Blank-final locals A **blank final** is a `final` local declared without an initializer: ```java final int y; if (cond) { y = 1; } else { y = 2; } ``` It follows definite assignment *and* the stronger 'assigned **exactly once**' rule — the compiler rejects a second assignment on any path. This lets you initialize a constant conditionally while still guaranteeing immutability. ## Loops and definite assignment Because a loop body's locals are recreated each iteration, a variable declared *inside* the loop must be assigned within that iteration before use; one declared *outside* must be definitely assigned before the first read regardless of whether the loop runs zero times. The compiler must assume a `while`/`for` may execute zero times unless the condition is a compile-time constant `true`. ## Why it matters Definite assignment turns a whole class of 'uninitialized variable' bugs (common in C) into compile errors. Knowing how it interacts with block scope and reachability lets you choose where to declare a variable and structure branches so the compiler can prove correctness — and explains many otherwise-puzzling 'might not have been initialized' errors.