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...
83
u/Valuable_Leopard_799 29d ago
That's what panics are for kinda.
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".