{"title":"break, continue & pass","description":"","content":"`break`, `continue`, and `pass` are three small keywords that change how your loops and code blocks behave. `break` walks out of a loop early, `continue` skips ahead to the next iteration, and `pass` does nothing at all. They look trivial, but each one solves a specific problem cleanly, and each has a sharp edge or two that's worth knowing before you write code that depends on them.\n\n---\n\n# `break`: Exit the Loop Early\n\nYou'll reach for `break` whenever you don't need to finish the loop. Maybe you found the item you were searching for. Maybe an error condition came up and continuing would be wasteful or wrong. Maybe you only wanted to process the first N items and the rest can be ignored.\n\nThe classic case is searching: scan a cart for a specific product, and stop the moment you find it.\n\n\n```python\ncart = [\"Wireless Mouse\", \"USB Cable\", \"HDMI Cable\", \"Webcam\"]\ntarget = \"HDMI Cable\"\n\nfound = False\nfor item in cart:\n if item == target:\n found = True\n break\n\nprint(\"Found?\", found)\n```\n\n\nWithout `break`, the loop would keep walking through `\"Webcam\"` even though we already had the answer. For a four-item cart that's invisible. For a list of ten thousand items, scanning past the match is wasted work on every iteration after the hit.\n\n`break` jumps to the first statement *after* the loop. It doesn't run any remaining body for the current iteration, and it doesn't run the rest of the loop. Control flow drops straight out.\n\nHere's the same idea in a slightly larger setting: stop processing on the first invalid item.\n\n\n```python\ncart_prices = [19.99, 4.99, -1.00, 14.99]\n\nvalid_total = 0\nfor price in cart_prices:\n if price < 0:\n print(\"Invalid price found, aborting:\", price)\n break\n valid_total += price\n\nprint(\"Valid total so far:\", valid_total)\n```\n\n\nThe loop adds the first two prices, hits the negative one, prints a message, and breaks out. The fourth price (`14.99`) is never seen. The variable `valid_total` keeps whatever value it had at the moment of the break, which is exactly what you want for a \"stop on first error\" pattern.\n\nA third pattern is \"process up to N items\": you stop deliberately after a counted number of iterations.\n\n\n```python\nrecently_viewed = [\"Wireless Mouse\", \"USB Cable\", \"Webcam\", \"HDMI Cable\",\n \"Bluetooth Speaker\", \"Keyboard\"]\n\nshown = 0\nfor product in recently_viewed:\n print(\"- \" + product)\n shown += 1\n if shown == 3:\n break\n```\n\n\nThis works fine, though for a fixed count you'd usually slice the list (`recently_viewed[:3]`) or use `itertools.islice`. Reach for `break` when the stopping condition is dynamic and depends on what you've seen along the way.\n\n`break` works the same way in a `while` loop. It exits the loop immediately, regardless of whether the loop condition would still be true.\n\n\n```python\nstock = 5\nsold = 0\n\nwhile True:\n if stock == 0:\n print(\"Sold out\")\n break\n stock -= 1\n sold += 1\n\nprint(\"Units sold:\", sold)\n```\n\n\nThe `while True` pattern is common when the natural exit condition is easier to express inside the loop body than as a loop header. The `break` is the actual exit; without it, you'd have an infinite loop.\n\n---\n\n# `continue`: Skip to the Next Iteration\n\n`continue` is the opposite move. Instead of leaving the loop, it abandons the rest of the current iteration and jumps back to the top to start the next one. In a `for` loop, that means moving to the next item from the iterable. In a `while` loop, it means re-testing the loop condition.\n\nThe most common use is filtering inside a loop: skip items that don't qualify, process the ones that do.\n\n\n```python\nprices = [19.99, 0, 14.99, -5.00, 4.99]\n\npaid_total = 0\nfor price in prices:\n if price <= 0:\n continue\n paid_total += price\n\nprint(\"Paid total:\", paid_total)\n```\n\n\nFree items (`0`) and the bad data (`-5.00`) get skipped. Every valid price is added. The loop never exits early; it sees every item, but only acts on some of them.\n\nAnother fit: skip out-of-stock items while you build a display list.\n\n\n```python\ncatalog = [\n {\"name\": \"Wireless Mouse\", \"stock\": 12},\n {\"name\": \"USB Cable\", \"stock\": 0},\n {\"name\": \"HDMI Cable\", \"stock\": 4},\n {\"name\": \"Webcam\", \"stock\": 0},\n]\n\navailable = []\nfor product in catalog:\n if product[\"stock\"] == 0:\n continue\n available.append(product[\"name\"])\n\nprint(available)\n```\n\n\nTwo products get skipped, two get appended. The flow reads naturally: \"for each product, if it's out of stock, move on; otherwise add it to the list.\"\n\nHere's a counting case: count how many full-price items are in a cart, ignoring discounted ones.\n\n\n```python\ncart = [\n {\"name\": \"Wireless Mouse\", \"price\": 19.99, \"discounted\": False},\n {\"name\": \"USB Cable\", \"price\": 4.99, \"discounted\": True},\n {\"name\": \"HDMI Cable\", \"price\": 14.99, \"discounted\": False},\n {\"name\": \"Webcam\", \"price\": 49.99, \"discounted\": True},\n]\n\nfull_price_count = 0\nfor item in cart:\n if item[\"discounted\"]:\n continue\n full_price_count += 1\n\nprint(\"Full-price items:\", full_price_count)\n```\n\n\nTwo of the four items are discounted, so they're skipped. The other two each bump the counter.\n\nHere's how `break` and `continue` differ at the level of control flow. The diagram traces a single iteration and shows where each keyword sends you.\n\n\n```mermaid\nflowchart TD\n START[Next iteration]:::cyan --> COND{Loop has
more items?}:::orange\n COND -->|No| END[After the loop]:::teal\n COND -->|Yes| BODY[Run loop body]:::cyan\n BODY --> CHECK{Hit a special
statement?}:::orange\n CHECK -->|continue| START\n CHECK -->|break| END\n CHECK -->|Neither| FINISH[Finish iteration]:::green\n FINISH --> START\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\n`continue` loops back to the top to ask \"any more items?\". `break` skips the question entirely and lands on whatever comes after the loop. Plain \"finish iteration\" is what happens when you reach the end of the loop body without hitting either keyword: the iteration completes normally, then the loop asks for the next item.\n\nA subtle point about `while` loops: `continue` jumps straight to the loop's condition test, which means anything you'd normally do at the *bottom* of the body, like incrementing a counter, gets skipped if it sits below the `continue`.\n\n**What's wrong with this code?**\n\n\n```python\ni = 0\nwhile i < 5:\n if i == 2:\n continue\n print(i)\n i += 1\n```\n\n\nThe program prints `0` and `1`, then hangs forever. When `i` becomes `2`, `continue` jumps back to the condition without running `i += 1`, so `i` stays at `2` and the same `continue` fires on every loop forever.\n\n**Fix:** Update the counter before the `continue`, or use a `for` loop where the counter is managed for you:\n\n\n```python\nfor i in range(5):\n if i == 2:\n continue\n print(i)\n```\n\n\nIn a `for` loop, the iterator advances on its own when control returns to the top, so `continue` is safe by default. In a `while` loop, you have to be careful that the loop variable still moves toward the exit condition before any `continue`.\n\n\n> **INFO**\n>\n> **Cost:** Neither `break` nor `continue` saves work in any magical way. They just change which lines of the loop body run and when the loop ends. The savings come from skipping work you would otherwise do, not from the keyword itself.\n\n\n---\n\n# `break` and `continue` Only Affect the Innermost Loop\n\nThis is the trap. `break` and `continue` always act on the loop they sit directly inside. They don't escape outer loops. People forget this, and end up with code that \"almost works\" until the data hits a case that exposes the bug.\n\nPicture a refund job that processes orders, where each order has multiple items. The intent is \"stop everything as soon as we hit one bad item.\" Here's the wrong way:\n\n\n```python\norders = [\n [19.99, 4.99, 14.99],\n [29.99, -1.00, 9.99],\n [49.99, 19.99],\n]\n\nprocessed = 0\nfor order in orders:\n for amount in order:\n if amount < 0:\n print(\"Bad amount, breaking:\", amount)\n break\n processed += 1\n\nprint(\"Items processed:\", processed)\n```\n\n\nThe reader expected the program to stop entirely at the bad amount, with `processed` equal to `5` (three items from the first order, then the two clean items from the second before the `-1.00`). Instead it kept going. The `break` only exited the *inner* loop, so the outer loop happily moved on to the third order and processed two more items.\n\nThere are two clean ways to fix this.\n\n**Fix 1: Use a flag variable.** Set a flag when the inner loop wants to abort, and check it in the outer loop.\n\n\n```python\norders = [\n [19.99, 4.99, 14.99],\n [29.99, -1.00, 9.99],\n [49.99, 19.99],\n]\n\nprocessed = 0\nabort = False\n\nfor order in orders:\n for amount in order:\n if amount < 0:\n print(\"Bad amount, aborting:\", amount)\n abort = True\n break\n processed += 1\n if abort:\n break\n\nprint(\"Items processed:\", processed)\n```\n\n\nNow both loops exit. The flag is the bridge: the inner `break` exits the inner loop, the outer `if abort: break` exits the outer one. It works, but the bookkeeping is noisy. Two breaks, one flag, and the reader has to scan both loops to be sure of the flow.\n\n**Fix 2: Extract the inner loop into a function and use `return`.** A `return` statement exits the function entirely, no matter how many loops it's nested inside.\n\n\n```python\ndef process_orders(orders):\n processed = 0\n for order in orders:\n for amount in order:\n if amount < 0:\n print(\"Bad amount, aborting:\", amount)\n return processed\n processed += 1\n return processed\n\norders = [\n [19.99, 4.99, 14.99],\n [29.99, -1.00, 9.99],\n [49.99, 19.99],\n]\n\ncount = process_orders(orders)\nprint(\"Items processed:\", count)\n```\n\n\nThis version is shorter, has no flag variable, and reads top-to-bottom. The function-extraction trick is the standard Python answer to \"I need to break out of nested loops.\" Most code that uses a flag for this would read better as a function.\n\nThe same rule applies to `continue`. An inner-loop `continue` only restarts the inner loop. If you want to skip to the next outer iteration, you need to structure your loops or your function differently.\n\n\n```python\norders = [\n [19.99, 4.99, 14.99],\n [29.99, -1.00, 9.99],\n [49.99, 19.99],\n]\n\nfor order in orders:\n if any(amount < 0 for amount in order):\n print(\"Skipping bad order:\", order)\n continue\n print(\"Processing order:\", order)\n```\n\n\nHere we replaced the inner loop with a single `any(...)` call so there's no nesting at all, and the outer `continue` does exactly what we want. Pulling the inner check into a separate expression or function is often a better fix than reaching for nested `break` and `continue`.\n\n---\n\n# `pass`: A Statement That Does Nothing\n\n`pass` is a no-op. It runs, takes no time worth measuring, and produces no effect. The reason it exists is purely syntactic: Python requires a non-empty body after `if`, `def`, `class`, `for`, `while`, `try`, and similar statements. If you have nothing to put there, you need *something* the parser will accept. That's `pass`.\n\nThe most common use is a stub: a class or function you've sketched the signature for but haven't implemented yet.\n\n\n```python\nclass Order:\n pass\n\ndef cancel_order(order_id):\n pass\n\norder = Order()\nresult = cancel_order(42)\nprint(order)\nprint(result)\n```\n\n\nBoth `Order` and `cancel_order` are completely empty, but Python accepts them. `Order()` creates an instance with no attributes or methods of its own. `cancel_order(42)` runs the empty body and returns `None`, which is what every function returns when it doesn't explicitly return anything.\n\nWithout `pass`, leaving the body empty is a `SyntaxError`:\n\n\n```python\nclass Order:\n\nprint(\"after\")\n```\n\n\nPython needs *something* indented under `class Order:`. `pass` fills that gap with a statement that does nothing observable.\n\nThe same pattern works inside `if` branches. Sometimes the rule you're modeling really has nothing to do in one of its cases, and a `pass` makes that explicit:\n\n\n```python\norder_status = \"shipped\"\n\nif order_status == \"cancelled\":\n pass\nelse:\n print(\"Processing:\", order_status)\n```\n\n\nThat `pass` says \"if the order is cancelled, do nothing here, on purpose.\" It's clearer than restructuring the `if` to invert the condition, especially if you expect to fill in real behavior later.\n\n`pass` also shows up in `try/except` blocks where you genuinely want to swallow a specific error. Here's a careful version that only ignores the error type you're prepared for:\n\n\n```python\nquantities = [\"3\", \"5\", \"abc\", \"7\"]\n\nvalid = []\nfor raw in quantities:\n try:\n valid.append(int(raw))\n except ValueError:\n pass\n\nprint(valid)\n```\n\n\nThe `int(\"abc\")` call raises `ValueError`, the `except` catches it, and `pass` says \"carry on.\" The bad input gets dropped, the good values are collected. This is a legitimate use, and it's narrow: we caught one specific error type, which is the one we expected.\n\nWhich brings us to a sharp edge.\n\n**What's wrong with this code?**\n\n\n```python\nquantities = [\"3\", \"5\", \"abc\", \"7\"]\n\nvalid = []\nfor raw in quantities:\n try:\n valid.append(int(raw))\n except:\n pass\n\nprint(valid)\n```\n\n\nThe output is the same, but the `except:` (with no exception type) catches *everything*: not just `ValueError`, but `KeyboardInterrupt` (the user hit Ctrl+C), `MemoryError`, programming bugs like `NameError`, and anything else that gets raised. Combined with `pass`, that means errors disappear silently with no log, no print, no chance to debug. A typo in the loop body becomes invisible.\n\n**Fix:** Always name the exception types you actually expect to handle.\n\n\n```python\nfor raw in quantities:\n try:\n valid.append(int(raw))\n except ValueError:\n pass\n```\n\n\nIf you genuinely want to log and continue, log first, then `pass` (or just don't bother with `pass`, since logging counts as a real statement and the `except` body is no longer empty).\n\n\n> **INFO**\n>\n> **Cost:** `pass` compiles to a `NOP` in Python's bytecode and has no measurable runtime cost. It's purely a parser convenience.\n\n\n---\n\n# `pass` vs `...` (the Ellipsis Literal)\n\nPython has a second placeholder that does almost the same job: `...`, the Ellipsis literal. Like `pass`, it's a valid statement on its own, so it satisfies the parser when a body is required.\n\n\n```python\nclass Refund:\n ...\n\ndef issue_refund(order_id):\n ...\n\nprint(Refund())\nprint(issue_refund(42))\n```\n\n\nBoth work identically here. The differences are in convention and in what they actually evaluate to.\n\n\n| Marker | What it is | Where it's idiomatic |\n| --- | --- | --- |\n| `pass` | A statement that does nothing | Empty bodies you don't intend to fill in (real no-op `if` branches, `except: pass`) |\n| `...` | The `Ellipsis` object, used as a one-line statement | Stub bodies you plan to implement later, type-stub files (`.pyi`), abstract methods |\n\n\nA common convention in modern Python code: `...` flags \"this is a placeholder I haven't implemented yet,\" while `pass` flags \"this body is intentionally empty.\" Both are valid in either spot, and Python doesn't care, but readers of your code might.\n\n`...` also has uses outside of stubs (it shows up in NumPy slicing, for example), while `pass` is a pure statement with no value. If you find yourself in doubt, `pass` is the canonical choice for empty bodies, and it's the version every Python programmer recognizes immediately.\n\n---\n\n# Common Mistakes\n\nA few traps come up enough to mention them explicitly.\n\n**Mistake 1: Assuming `break` exits all loops.** Covered above. `break` exits exactly one loop, the innermost one it sits in. If you need to leave nested loops, use a flag or refactor into a function with `return`.\n\n**Mistake 2: Reaching for `continue` when an inverted condition would be clearer.** `continue` is great when there are several skip cases or when the \"do the work\" branch is long. For a single skip, an inverted `if` often reads better.\n\n\n```python\nprices = [19.99, 0, 14.99, 4.99]\n\ntotal_a = 0\nfor price in prices:\n if price == 0:\n continue\n total_a += price\n\ntotal_b = 0\nfor price in prices:\n if price != 0:\n total_b += price\n\nprint(total_a, total_b)\n```\n\n\nBoth versions produce the same result. The `continue` form is fine, but for a single check, the `if price != 0` form is shorter and avoids introducing a control-flow keyword. Save `continue` for cases where the body after it is long, or where you have several different skip conditions to filter on.\n\n**Mistake 3: Using `pass` where a comment or `raise NotImplementedError` would communicate intent better.** A bare `pass` in a stub function silently returns `None`, which can hide bugs. If a function isn't implemented yet, raising an error makes that obvious the moment something tries to call it.\n\n\n```python\ndef issue_refund(order_id):\n raise NotImplementedError(\"issue_refund is not implemented yet\")\n\nissue_refund(42)\n```\n\n\nThat traceback tells you exactly what's missing. A `pass` would have silently returned `None` and let the rest of your code limp along on bad data. Use `pass` when the empty body is *intentional* (a real no-op branch, an expected error to swallow), and use `raise NotImplementedError` (or `...` plus a TODO comment) for \"I haven't gotten to this yet.\"\n\n**Mistake 4: `continue` in a `while` loop above the variable update.** The earlier \"infinite loop\" example. In a `while` loop, anything you `continue` past is skipped, including the lines that move the loop toward its exit. Either move the update above the `continue`, or restructure as a `for` loop.","pageType":"python"}

break, continue & pass

Get Premium