3 ms·
It depends what kind of program it is. A long running GUI program probably doesn't want to completely abort if the user tries to open file that it doesn't have
by __david__ 16y ago
It depends what kind of program it is. A long running GUI program probably doesn't want to completely abort if the user tries to open file that it doesn't have enough memory to process--especially if there are other unsaved documents open.
Similarly an embedded program might not want to reboot itself if there aren't enough memory resources to carry out a command (due to other commands being processed at the same time).
But you are right, a lot of the time (perhaps even the majority of the time) it really is perfectly acceptable to just die if you can't malloc().
And it really does take a lot of effort to manage memory like that, but if it is done right it can really make things work robustly.
- tptacek 16y agoYour allocation failure strategy is orthogonal to how individual allocations should be handled. In a UI program, keep a reserve of memory, return valid addresses to the caller, and pop up a warning. It's actually easier to do things like this if you aren't hand-crafting individual little alloc-check-handle routines.
- __david__ 16y agoThat seems full of edge cases. If your reserve isn't big enough it doesn't help and if it's too big then it's a waste. It seems much cleaner to be able to gracefully abort whatever operation you were doing. Presumably there is already error handling for fs/network errors. Usually you can hop onto those handlers with memory errors and be just fine. Though if it's linux it'll just kill you anyway :-). (Yeah, I know you can turn the OOM killer off).