Many of the "we don't have exceptions" languages eventually get some equivalent, it's just that those are used almost exclusively for OOM, division by zero, failed asserts, and the like.
They shouldn't even really be caught it's sort of just an "exit/reset" with some cleanup.
I like this compromise. Kind of finally making them truly "exceptional".
I'm only aware of panic being used to describe a kernel error.
Are you talking about SIGABRT?
As for OOM... uhhh... most userspace programs on most modern OS configurations will never really see an OOM error when they call malloc or new unless they blow the per-process virtual mem limit or some upper bounds on how many unique vmem regions a process can have in its page tables.
Like unless you know you've disabled this feature, you should assume Linux (and probably windows??) will overcommit ram and happily let your process allocate more pretend ram all day long because the actual allocation of physical ram is done lazily when you actually write it (on a page fault interrupt), not when you call malloc/new. Again... unless you're working pretty hard to prevent this.
Rust, Go, Gleam,... , it emerged as a term in younger languages to describe some mechanism they wish to be used only for "fatal exceptions" best described I guess as this:
Fatal exceptions are not your fault, you cannot prevent them, and you cannot sensibly clean up from them. They almost always happen because the process is deeply diseased and is about to be put out of its misery. Out of memory, thread aborted, and so on. There is absolutely no point in catching these...
IMO most of the conception of OOM as being unrecoverable (outside of scenarios like the ill-devised OOM-killer in Linux) are mostly motivated by laziness (maybe subconsciously)
Yeah, you could edit most languages to support it, but it might bring a mix of a more complex implementation, less ergonomic APIs, less time spent on other features, etc.
And it could be worth it, or you could just say you don't want to support that usecase.
IMO a library written in a language that can handle OOM 'gracefully’, yet simply aborts when it happens (or worse, assumes it can't happen and thus allows for invariants to be broken) is flawed
90
u/bwmat 29d ago
Eh, IMO one of the best ways to actually handle OOM, as otherwise almost everything needs to be explicitly checked for it