Make cleanup someone’s actual job.

The mess

Your AI puts cleanup at the bottom. Then you add an early return. Congratulations: a one-line edit now needs an incident report.

RAII ties cleanup to an object's lifetime. The acronym means Resource Acquisition Is Initialization. Apparently “automatic cleanup” wasn't hostile enough for the naming committee.

void update() {
    mutex.lock();
    if (!ready()) return; // Everyone else can wait. Forever, possibly.
    mutex.unlock();
}

Here mutex and ready() already exist. That return skips the unlock. Other callers may get stuck waiting.

The fix

Use std::lock_guard: construction acquires the mutex; destruction releases it. Think automatic key return, instead of trusting every guest to remember checkout.

Constructed local guards are destroyed on ordinary scope exits, including early returns and exception unwinding. Existing owners also manage files and memory.

Forced process termination doesn't guarantee destructors run. RAII handles cleanup, not resurrection. You paid for autocomplete, not an exorcism.

Ask your AI

Replace manual cleanup with an appropriate RAII owner. Show where it is destroyed on success, early return, and exception paths.

Cleanup belongs in the design, not in your increasingly optimistic memory.

Receipts: RAII guideline · Lock guards.