Lars Wirzenius
liw@toot.liw.fi
It turns out that it's often a good idea to start the work to design code by figuring out how to handle errors and failures, rather than the happy path.
Adding error handling later is often difficult and can break the happy path.
Also, if you start with that, it's easier to design how to test it, too.
1
0
0
@liw I’ve tried this for out of memory conditions (aka memory exhaustion) in Rust but there’s no -ENOMEM :-) In unstable there is handle_alloc_error() but it is. sort of complicated track to adapt. Would be nice if you could do this every and each at the site, as callback indirection sucks…
In this thread I see one common and wrong conclusion:
“Yeah, but there are also other application areas, such as embedded environments with less RAM and no memory overcomittment.”
For restricted embedded payloads and stuff like that you usually define metrics already at the compile time, and use crates such as heapless. It is exactly dynamic over-committed memory where it would be nice to explicitly deal with this unexpected corner case.
It is pretty hard to sometimes discuss about memory issues in Rust with “rustaceans” because they are living in the myth of Rust being memory-safe. Nothing is never fully memory-safe.
1
1
0
0
0
0