@Changaco In non-garbage collected languages like #Rust or C++ the problem with exceptions (and panic is kind of exception with limited options for handling) is that the stack unwinding is non-deterministic and code heavy. So in contexts like embedded systems, very problematic (that's why on embedded we turn off exceptions in C++). With handling errors, the cost is explicit in the code.

#C++23 introduced `std::expected<>` for that reason, but SL doesn't use it yet for anything.

@Changaco The OOM handling situation in Rust is not caused by panics, and the problem is limited to the standard library, not the language.

It was a conscious design decision to just give up and not even bother to recover from OOM, because Linux has overcommit which makes OOM practically impossible to observe. It makes C malloc() interface broken and checking futile, because it doesn't fail on allocation, only sometime later when you write to some bytes to RAM that happen to cause page faults.

@Changaco If you're writing a library in Rust then you should never allow your code to panic, you should instead have fallible functions return the `Result<T, E>` container and allow the client (application) code to decide how to handle a Result which contains an error instead of a successful payload.

I have to say I prefer this model to that of exceptions (and that's based on years of experience in Java).