Loops & Branching

## The rule in one line In a Dart 3 `switch` **statement**, a **non-empty** `case` body runs and then control jumps to the end of the switch. There is no implicit fall-through into the next case, and no `break` is needed. An **empty** case, one with no statements, falls through to the next case so that several cases can share one body. ## How it looks ```dart switch (command) { case 'OPEN': executeOpen(); // runs, then leaves the switch case 'DENIED': // empty: falls through case 'CLOSED': executeClosed(); // runs for DENIED and CLOSED default: executeUnknown(); // runs when no case matches } ``` - **`default`** or the wildcard **`_`** handles values no case matched. - A non-empty case may also end with `continue`, `throw` or `return`; `break` still works but is redundant at the end of a body. The `unnecessary_breaks` lint flags that leftover `break`. - An **empty case that should do nothing** (rather than fall through) gets `break;` as its only statement. ## What changed in Dart 3.0, and what did not | | Before Dart 3.0 | Dart 3.0 and later | |---|---|---| | Non-empty case without `break` | compile error (`switch_case_completes_normally`) | allowed; jumps to the end | | Implicit fall-through from a non-empty case | never | never | | Empty case | falls through | falls through | | What a `case` holds | a constant expression | a **pattern** (constants still work) | The important point for an interview: Dart has **never** silently fallen through from a non-empty case. Before 3.0 the language forced you to write `break` (or `continue`, `return`, `throw`) and reported an error otherwise; Dart 3.0 simply made the `break` implicit. Code ported from a C-family language that relies on fall-through does not compile in old Dart and does not fall through in new Dart. ## Deliberate fall-through: `continue` with a label When one case really should run another case's body afterwards, you say so explicitly. Put a **label** on the target case and end the source case with `continue label;`: ```dart switch (command) { case 'OPEN': executeOpen(); continue closed; // jump into the CLOSED body closed: case 'CLOSED': executeClosed(); } ``` This is rare in practice, and reviewers usually prefer a shared helper function, but it is the only way to get a non-sequential or multi-body flow in a switch statement. ## `break` inside a switch inside a loop Inside a `switch`, an unlabelled `break` ends the **switch**, not an enclosing loop. That surprises developers who expect `break` to leave the loop: 1. The `break` exits the switch. 2. The loop continues with its next iteration. 3. To leave the loop from inside a case, put a label on the loop and write `break loopLabel;`, or `return` from the function. ## Related rules you should mention but not confuse - **Cases are patterns** since 3.0, so a case can be a constant, a range with relational patterns or several alternatives joined with `||`. Pattern syntax itself is its own topic. - **Switch statements on enums, sealed types and `bool` are checked for exhaustiveness**: the analyzer reports `non_exhaustive_switch_statement` if a value could slip through with no matching case. Adding a `default` silences the check for future enum values too. - **Switch expressions** (`final label = switch (x) { ... };`) are a different construct with their own rules: no empty cases, no fall-through at all, `=>` bodies. ## What an interviewer listens for - "Non-empty cases don't fall through and don't need `break` in Dart 3." - "Empty cases share the next body." - "Old Dart required `break`; it was never a silent fall-through." - "`continue label` is the explicit fall-through; `break` in a switch only leaves the switch."