It is impractical to try to recover/continue your program in an out of memory situation for most programs.

So it is a good advice for beginners.

smj-edison 15 hours ago | parent | next [-]

I think this is fair the majority of time, but I'd like to mention Zig, since Zig has a convention of all allocations being fallible and handled. It's a pain at first to handle error.OutOfMemory at each allocating site, but I feel like I'm much more conscious of where allocation can fail and how to gracefully handle it. I've also gotten a lot better at transactions since pretty much every operation has failure points now.

In fact I've written a whole interpreter that can recover from OOM by raising a recoverable exception to the user. It's really only because Zig made recovering idiomatic, and I'm not sure I could've done it in another language (maybe Rust but I'd have to rewrite large parts of stdlib to both return an error and take a custom allocator).

▲

steveklabnik 11 hours ago | parent | next [-]

The Rust stdlib has added those functions that return errors, and the types are parameterized by the allocator trait. The trait is coming to stable in the next release!

▲

smj-edison 10 hours ago | parent [-]

Oh that's exciting! I knew about the allocator work, but I hadn't heard about error reporting for failed allocations, or that it was about to be stabilized.

	▲	steveklabnik 9 hours ago \| parent [-]
		To be specific, I’m talking about try_ variants of functions that allocate and return Result. I’m not sure when those are becoming stable, but Rust for Linux has been driving a bunch of this work, in my understanding, so that’s helped a lot.

▲

mappu 7 hours ago | parent | prev [-]

In userspace/application code this isn't giving you all the value you hope for - because of overcommit and fork/exec, you can OOM on simply modifying a variable (in a non-file-backed page).

What Zig does is great, but it is not actually comprehensively checking that all allocations are fallible and handled. That's not possible on Linux.

	▲	smj-edison 5 hours ago \| parent [-]
		Unless you use cgroups or turn off overcommit :) I'm also hoping to use the core interpreter on memory-limited devices like an ESP-32.

▲

layer8 16 hours ago | parent | prev | next [-]

If the code is in a library (and I’d treat code as if being part of a library by default), then the library shouldn’t be deciding that.

▲

1718627440 15 hours ago | parent | prev [-]

But in order to able to show proper diagnostics and error messages, you should still return all the way to the top.

	▲	im3w1l 15 hours ago \| parent [-]
		No one does this. The best you can hope for is that a rare few especially error prone allocations (perhaps they are huge, or user controlled) are handled. Someone might I suppose also wrap all malloc calls in a function that shows a dialog or error message and only then exits. But returning all the way to the top, yeah.. no..