^^^ - This - my recent one, came to the realization that dealing with memory mapped files is much harder without exceptions (not that exceptions make it easier, but at least possible).

Why? Let's say you've opened a memory mapped file, you've got pointer, and hand this pointer down to some library - "Here work there" - the library thinks - oh, it's normal memory - fine! And then - physical block error happens (whether it's Windows, OSX, Linux, etc.) - and now you have to handle this from... a rather large distance - where "error code" handling is not enough - and you have to use signal handling with SIGxxx or Windows SEH handling, or whatever the OS provides

And then you have languages like GoLang/Rust/others where this is a pain point (yes you can handle it), but how well?

If you look in ReactOS the code is full with `__try/__except` - https://github.com/search?q=repo%3Areactos%2Freactos+_SEH2_T... - because user provided memory HAVE to be checked - you don't want exception happening at the kernel reading bad user memory.

So it's all good and fine, until you have to face this problem... Or decide to not use mmap files (is this even possible?).

Okay, I know it's just a silly little thing I'm pointing here - but I don't know of any good solution off hand...

And even handling this in C/C++ with all SEH capabilities - it still sucks...

If the drive fails and you get a signal it’s perfectly valid to just let the default signal handler crash your process. Signals by definition are delivered non-locally, asynchronously, and there’s generally nothing to try/catch or recover. So handling this in Rust is no different than any other language because these kinds of failures never result in locally handleable errors.