Why does a scope release its resources in the reverse of the order in which they were acquired?

## Acquisition is a stack Inside one scope, the guards are constructed one after another, and each later one may legitimately use an earlier one. That makes the set of live resources a **stack**, not a bag: - a lock is taken, and only under it is a temporary file created in the protected directory; - a buffer is allocated, and a connection is then opened that writes from that buffer; - a connection is opened, and a transaction is begun on it. In each case the later resource holds a reference, a handle or an implicit assumption about the earlier one. **Reverse-order teardown is the only fixed rule under which a resource is released before everything it depends on.** Acquisition order would invert every one of those relationships: freeing the buffer while the connection still writes from it, releasing the lock while the file it protects is still open, closing the connection out from under an open transaction. ## The rule, stated precisely Within a scope, guards are destroyed in the reverse of the order in which they were **constructed** — not the order in which they were declared, and not an order the compiler is free to pick. Two consequences follow: 1. **A guard whose constructor did not complete is not in the stack at all**, so it is skipped entirely and the ones below it are still released in reverse. 2. **Nested scopes compose.** An inner block's guards are all released at the end of that block, before any of the outer block's guards; the whole program's teardown is one last-in-first-out unwinding of nested scopes. | acquisition inside the scope | teardown under reverse order | teardown under acquisition order | |---|---|---| | lock, then temp file, then connection | connection, temp file, lock | lock released while the file it guards is open | | buffer, then connection using it | connection, buffer | buffer freed while the connection still reads it | | connection, then transaction on it | transaction, connection | connection closed under an open transaction | ## What it buys the author The deeper benefit is that the rule is **unconditional**. Even when two guards in a scope are genuinely independent — an unrelated metrics timer and a file handle — the order is still fixed, so no reader has to reason about whether the independence holds, and no reviewer has to re-check it when a fourth guard is added between them. You get the correct order for the dependent cases for free, and a harmless deterministic order for the rest. Contrast that with a hand-written cleanup block. There the release order is typed out, so it is a thing that can be wrong, and it commonly is: someone adds an acquisition at the top and appends its release at the bottom, quietly producing acquisition-order teardown for that pair. The failure is invisible in the ordinary case, because the dependency is usually tolerant, and shows up as a rare crash or a rare 'handle used after close' in production. ## Where the rule is silent Reverse order is a statement about **one scope's locals**. It says nothing about: - **resources owned elsewhere** — something whose owning object lives in an outer scope or a longer-lived structure is released when *that* owner ends, which may be much later; - **the order of two sibling scopes** — a block that ends before another begins has already fully torn down, so there is no interleaving to reason about; - **releases that must be sequenced against work outside the scope**, such as telling a downstream system you are done before you drop the connection. That sequencing has to be written explicitly inside the scope; teardown only guarantees the relative order of the guards it owns. A useful way to say it in an interview: construction is a push, destruction is a pop, and the scope is the stack. Everything else about the ordering follows from that one sentence.