When a scope exits because an error is unwinding, what must a guard's release do differently from a normal return?

## Teardown does not know why the scope ended The scope's teardown is the same code on both paths — it destroys the guards it owns, in reverse order. What differs is the **outcome the guard should choose**, and a destructor is not handed the reason the scope ended. The standard design therefore inverts the question: instead of asking 'did an error happen?', the guard asks 'was I told the work completed?'. That gives the two-state guard: 1. Construction acquires the resource and records `completed = false`. 2. An explicit call inside the scope — commit, publish, flush, hand over — does the work whose failure matters, checks it, and sets `completed = true`. 3. The destructor performs the **abandon** outcome unless `completed` is set. The abandon outcome is the safe default because it is the one that is correct when the scope ended unexpectedly, and unexpected exits are exactly the ones nobody wrote code for. | resource | success outcome (explicit) | abandon outcome (destructor default) | |---|---|---| | transaction | commit, error checked by the caller | roll back | | temporary export file | rename into place as the published file | delete the partial file | | buffered writer | flush and confirm durability | discard the unwritten bytes | | lock | nothing — release is the only outcome | release | | pooled connection | return it to the pool as reusable | return it marked broken, or close it | The lock row matters: some resources have exactly one outcome, and for those the plain guard with no completion call is complete and correct. ## The second rule: do not fail while failing A destructor has no caller to return a status to. During unwinding there is already a failure in flight, and a release that raises a second one leaves two failures and one channel. Designs differ in what happens then — the original failure can be replaced by the newer one, the newer one can be swallowed, or the whole process can be brought down — and none of those is a good outcome to design for. The rule that follows is blunt: - **A release whose failure changes correctness must not be left to teardown alone.** Flushing bytes that must reach durable storage, committing, acknowledging receipt: do it explicitly, inside the scope, where the failure has a caller. - **Teardown does the best-effort part**: close the handle, unlock, discard, roll back — and swallows or records its own errors rather than propagating them. This is not an argument against scope-bound release; it is what makes it complete. The explicit call handles the reportable outcome, the destructor handles every path where that call never happened. ## Partial construction, again Unwinding out of the middle of a scope's own setup is the same rule applied one level down. The guards already fully constructed are destroyed in reverse; the one whose constructor was in flight is not, since it never became an object with an obligation. Practically: a constructor that acquires two things should hold each in its own member guard, so that a failure of the second releases the first automatically rather than requiring a hand-written cleanup inside the constructor. ## What an interviewer is listening for - That teardown **runs** on the unwinding path — many candidates assume an error path skips it, which is the whole reason manual release at the bottom of a function is a defect. - That the guard defaults to **abandon**, not to commit. A guard that commits on destruction turns an abandoned scope into published bad data, which is far worse than a leak. - That there is a distinction between a release that can fail meaningfully and one that cannot, and that the first gets an explicit checked call. - That the guard can record the anomaly: being destroyed without completion is legitimate on an error path, but a guard that logs or counts it turns a silent abandon into an observable one. Said in one line: the scope guarantees the release happens; the guard decides which release it is, and the safe default on the path nobody planned for is to undo rather than to finish.