Leaving scopes during propagation
An exception not handled locally can transfer control toward an enclosing handler. Unwinding specifies how intervening calls and scopes are left and which cleanup actions accompany propagation.
The C++ working draft requires destruction of relevant constructed automatic-duration objects in reverse order of completed construction. This is not merely discarding stack storage without honoring object-lifetime rules.
References: [1]
Partial construction has cleanup rules
A constructor can throw after some bases or members have completed initialization. C++ specifies cleanup of those completed subobjects rather than pretending the whole enclosing object finished construction.
Resources owned by correctly designed members can participate in this automatic cleanup. A raw handle without a corresponding ownership mechanism does not acquire a suitable release action merely because unwinding occurs.
Cleanup and business rollback differ
Releasing a lock or local resource does not recall a delivered notification or undo an unrelated remote change. Unwinding enforces language and object-lifetime rules, not arbitrary reversal of the outside world.
Termination or abort paths can have different cleanup behavior from normal propagation. Interfaces must identify which errors unwind, who owns resources, and how other failures are reported instead of assuming that a catch clause completes every recovery task.