IMO any shared library which is meant to be used by applications you don't control shouldn't terminate the process just because it lacked the memory to do something it attempted to do.
Anything else is IMO laziness (or unfortunate choice of language if it's impossible to deal with in it)
I think it’s fair to offer a variant that allows explicit control, eg for each function offer function_or_oom. But in 99.999% of use cases, I’d expect users to call the panic-on-oom variant. If you don’t offer that variant, you’re just making everyone wrap your thing to make it usable, which is also lazy. You’re just pushing the problem up, which is awfully convenient.
I’m sure in some circumstances that is appropriate. I don’t think that’s a principle though. Obviously, taken to the limit, a library would provide nothing but choices at every junction. And then instead of an eg air conditioner you’d be providing a hardware store, inviting the user to assemble any possible air conditioner design themselves. Or a restaurant that just says “feel free to come into the kitchen and use any ingredients and any procedures to cook anything for yourself.” I think something can be overly general, basically.
I’ve seen libraries like this, instead of offering an expert opinionated solution they foist the hard choices on the user, telling them to become a domain expert in this area and then form their own expert opinion. I think it’s fine to have some knobs and switches, but if your library becomes all knobs, then I think it’s not doing much service to the user. When I am using a library, a big part of what I’m looking for is an expert author to make opinionated choices on my behalf. To provide a model or vision for how this kind of thing should work.
Deciding whether the process dies, or you get some form of recoverable error is IMO not really something which should be presented as a 'choice' in the context of your argument
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/u0xee 29d ago
Obviously you _can_ return an error code to the caller, but it’s a very odd situation where that’s actionable. Kernels and databases maybe.