Does it make sense to continue execution after catching EOutOfMemory
exception or now heap or stack is corrupted with a high probability?
I don't mean the case of EOutOfMemory
caused by previous memory corruption due to bugs like writing to a wild address, I mean correct code that calls GetMem
and catches EOutOfMemory
.
In my opinion, there's no point attempting to continue from EOutOfMemory
. In my experience, chances are exceedingly high that the heap will be corrupted and future errors can be expected. Usually, the safest course of action is to terminate the process.
In general, I agree that there's no point trying to recover. But it can be useful in specific circumstances. For example, allocating large amounts of memory that depend on user choices, and if it fails you can back out cleanly and let them retry with different settings. I do this for converting point clouds to 3D meshes, which includes some steps where the memory requirements aren't known in advance. It just takes careful coding of the steps you want to be recoverable, with an immediate and clean backout path. For example, some of my data structures are bitmaps or buffers with each line allocated separately to minimize issues with fragmented memory. The constructors have try... except handling and throw an EOutOfMemory exception, and the destructors free any of the lines that were already allocated. I can't guarantee it will always work, but it has worked well enough to be worth doing.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With