RES38-C. Do not leak resources when throwing exceptions

It is important that resources are reclaimed when exceptions are thrown. Throwing an exception may result in cleanup code being bypassed. As a result, it is the responsibility of the exception handler to properly clean up. This may be problematic if the exception is to be caught in a different function or module. Instead, it is preferable if resources are reclaimed automatically when objects go out of scope.

Non-Compliant Code Example

while (moreToDo) {
   SomeType *pst = getNextItem();
   try {
      pst->processItem();
   }
   catch (...) {
      // deal with exception
      throw;
   }
   delete pst;
}

The code of the Non-Compliant Code Example does not recover the resources associated with the object pointed to by pst in the event that processItem throws an exception, thereby potentially causing a resource leak.

Compliant Solution

while (moreToDo) {
   SomeType *pst = getNextItem();
   try {
      pst->processItem();
   }
   catch (...) {
      // deal with exception
      delete pst;
      throw;
   }
   delete pst;
}

In this code, the exception handler recovers the resources associated with the object pointed to by pst.

It might be better to replace the pointer pst with an auto_ptr that automatically cleans up itself.

Risk Assessment

Memory and other resource leaks will eventually cause a program to crash. If an attacker can provoke repeated resource leaks by forcing an exception to be thrown through the submission of suitably crafted data, then the attacker can mount a denial-of-service attack.

References

[[Meyers 96]] Item 9: "Use destructors to prevent resource leaks".

RES37-C. Release resources that require paired acquire and release in the object's destructor      08. Memory Management (MEM)      MSC17-CPP. Do not use longjmp