How does definite-assignment analysis handle loops, try/catch/finally, and statements that complete abruptly (return/throw/break)?

## Key idea: the analysis follows control flow exactly Definite assignment (DA) tracks, at each program point, whether a variable is assigned on **every** path that can reach it. To do that the compiler has a precise rule for each control structure, including how a structure can be **entered**, **exited normally** (fall through), or exited **abruptly**. ## Abrupt completion A statement **completes abruptly** when it transfers control somewhere other than the next statement: `return`, `throw`, `break`, `continue`. The opposite is **normal completion** (falling through to the next statement). Code reached only after an abrupt statement is **unreachable** along that path, so the compiler does not require a variable to be assigned there — and conversely, the analysis can conclude a variable is definitely assigned by *eliminating* the path that left early: ```java int x; if (cond) { x = 1; } else { return; // abrupt: this path leaves the method } System.out.println(x); // x is DA here — the only path that reaches it set x=1 ``` Even though only the `if` branch assigns `x`, the `else` branch never reaches the read, so on every *reachable* path `x` is assigned. ## Loops: the body may run zero times A `while`/`for` body is not guaranteed to execute, so an assignment inside it does not establish DA afterward: ```java int x; while (cond) { x = 1; } System.out.println(x); // ERROR: loop might run zero times ``` **Exception — `while (true)`**: if the condition is the boolean constant `true` and there is no reachable `break` that can exit the loop, then the statement *after* the loop is unreachable, so DA there is vacuously satisfied (in fact the code after won't compile if truly unreachable). The compiler special-cases constant conditions. ```java int x; while (true) { if (ready()) { x = 1; break; } } System.out.println(x); // x is DA: the only way out is the break, which set x ``` Here the only exit is the `break`, and `x` is assigned before it, so `x` is DA after the loop. This is the loop counterpart of the abrupt-completion reasoning. ## try / catch / finally - **try → catch**: *any* statement in the `try` can throw before completing, so at the start of a `catch` block the compiler assumes **none** of the try's assignments necessarily happened. A variable assigned only inside `try` is therefore **not** DA in the `catch`. ```java int x; try { x = compute(); } // compute() might throw before assigning catch (Exception e) { System.out.println(x); // ERROR: x not DA here } ``` - **finally always runs**: a `finally` block executes on every exit path (normal or exceptional). So a variable definitely assigned **in** the `finally` is DA after the whole `try` statement. ```java int x; try { risky(); } finally { x = 0; } System.out.println(x); // OK: finally runs on every path, so x is DA ``` ## switch For a `switch`, a variable is DA after the statement only if it is DA at the end of every case that can fall out **and** there is a `default` (otherwise an unmatched value skips the whole switch). Fall-through between cases carries DA state forward as you'd expect. ## Why this design The rules are **sound** (they never let an unassigned read through) while staying purely structural and decidable at compile time. The cost is conservatism in a few spots — most famously the "assigned only in `try`, read in `catch`" case — because the compiler must assume the worst about where an exception could be thrown. ## Practical takeaways - Initialize before a `try` if you need the value in `catch`/after. - `while(true){…break;}` lets you assign-once after the loop without a redundant default. - An early `return`/`throw`/`break` in the *other* branch can satisfy DA on the surviving path — a common idiom for guard clauses.