It’s faulty app logic, assuming an io error cannot occur accessing a filesystem. They’ll also crash if you have disk issues or driver problems. The important thing is they may not even realize they’re calling into a function or routine that can access the fs for something!

All io access needs to be recoverable or catchable for your app not to crash. You’d be surprised how much background fs activity there can be in apps (or indirectly triggered by apps!) all the time.

This is one reason where I think Rust shines, and has even improved how I write C++.

So many areas where rust makes me deal with a result or option that are easy to take for granted. It’s a strong reminder of the number of things we should be treating as possible error cases

It makes you do something, but if the consumer just does .unwrap() the end result is going to be the same.

Sure, but a developer can also write any number of other code that’s irresponsible. At that point the language has done all it can for them, and the onus is on the developer to not be lazy.

And when the crash happens, it’s obvious why

That and sandboxing effects with perhaps improperly accessed bookmark data

I'm building a macos app now, and only because I wasn't catching fs access error did I realize I needed to handle folder access carefully when using bookmarks in core data.

I swear _Finder_ has this bug if you plug in a superannuated external HDD.

Stuff like this with NFS was my living nightmare for years. On Linux it would put processes into the D state and you'd have to restart the entire machine to fix anything.

SMB really is hell. I write business software and our admins do what they can to avoid using it because it's very hard to know when it fails.

But from a dev perspective, that's probably a driver level issue because that's where you want to handle or propagate errors instead of crashing.