In a Postman test script, how does a throw inside a pm.test block differ from a throw outside one?

## Two different error paths A Postman script has two places an error can land, and they behave nothing alike. Inside `pm.test(name, fn)`, the sandbox runs `fn` in a try/catch of its own. When the body throws, the catch marks that block's record `passed: false`, stores the thrown value in the record's `error` field, and emits the record anyway. Control then returns to the line after the `pm.test(...)` call. The script is not interrupted. Outside any block — at the top level of the script — there is no such wrapper. A throw propagates out of the script body, ends the execution, and is dispatched as an **execution error**. It is not an assertion result: it has no name, no index, and no pass/fail flag, because no block ever existed to hold it. | | throw inside `pm.test` | throw at script top level | |---|---|---| | caught by | the block's own try/catch | nothing in the script | | recorded as | one failed assertion record | an execution error | | carries a name | yes, the block's name | no | | gets an `index` | yes | no | | rest of the script | keeps running | does not run | | later `pm.test` blocks | still run and report | never created | ## Why this is the point of wrapping checks The containment is the reason to put every claim inside a block rather than writing bare `pm.expect` calls in sequence. A bare expectation that fails takes the whole script with it, and everything you would have learned from the remaining checks is lost. The same expectation inside a block costs you exactly one red line and nothing else. So the failure mode to watch for is not the assertion — it is the **setup** you leave outside: - `const body = pm.response.json();` at the top of the script throws on an HTML error page, and no block runs at all. - `const id = body.data.id;` throws a TypeError when `data` is absent, with the same effect. - A `JSON.parse` of a variable that was never set does it too. In each case the run reports one execution error and zero assertions — which reads, to anyone skimming, like a script that did not exist rather than a service that misbehaved. ## Making setup safe There are two honest ways to keep top-level code from erasing the report: 1. **Pull the risky parsing inside a block.** Parse the body inside the first `pm.test` and assert on it there. If parsing fails, that block fails with a readable name and every later block still runs and reports. 2. **Guard it.** Read defensively at top level — optional access, a default value, a `try`/`catch` you own — so that a missing field produces a failing assertion rather than a dead script. Both are better than the third option people reach for, which is wrapping the whole script in one giant block. That trades a dead script for a single opaque red line and loses every other verdict along the way. ## What a reader sees afterwards The distinction matters most when someone else reads the run. A failed block is a claim that was made and disproved; its name says what was expected. An execution error is a script that fell over; nobody can tell from it whether the service was healthy, because no claim was ever evaluated. When a report shows an execution error, the first question is always "what did the script do before any block ran", and the answer is almost always an unguarded parse or property read. ## The asymmetry is one-directional One last detail worth stating plainly: containment protects the script from the block, not the block from the script. A failing block cannot stop the ones after it, but anything that goes wrong between blocks can stop all of them. That asymmetry is why the useful habit is "put code inside blocks by default, and only hoist to top level what you are sure cannot throw".