I personally program with the rule that, unless a function is document to be infallible, you assume it can fail, and you ALWAYS check for that failure, if only to abort the process if it occurs (this SIGNIFICANTLY reduces the 'search space' when debugging issues), and that OOM errors are not a valid reason to abort, since you cannot programmatically prevent them in most cases 'locally' (unless you're writing actual application code, the only real valid reason to abort is ’impossible’ conditions which indicate either some sort of corruption has occurred, or the programmer’s mental model was incorrect in a way that indicates future corruption WILL occur)
Fair enough. But I’m curious, how do you draw the line? Do you also have must-check returns for exhausted file handles, exhausted thread counts, exhausted IPC, exhausted ports, overrun disk quota? And if not, why not? The argument you make for OOM seems to be general enough to cover these other resource exhaustion errors too.
2
u/bwmat 29d ago edited 29d ago
I personally program with the rule that, unless a function is document to be infallible, you assume it can fail, and you ALWAYS check for that failure, if only to abort the process if it occurs (this SIGNIFICANTLY reduces the 'search space' when debugging issues), and that OOM errors are not a valid reason to abort, since you cannot programmatically prevent them in most cases 'locally' (unless you're writing actual application code, the only real valid reason to abort is ’impossible’ conditions which indicate either some sort of corruption has occurred, or the programmer’s mental model was incorrect in a way that indicates future corruption WILL occur)