Side note: can we make 'file not found' errors that fail to mention what wasn't found illegal? What's the point of 'file not found', then keeping silent about the exact file? Seen it in various ecosystems now.
[0]: https://www.lurklurk.org/effective-rust/macros.html#when-to-...
¹: The one time out of ten is things like a script with a #! line that refers to a file that doesn't exist. The file you asked for (the script) definitely exists, but you'll get a file-not-found error if you ask the kernel to run it. Modern versions of bash seem to detect this situation and display a more helpful error message, but this is specific to bash, not other shells or languages.
There's no need for an allocation: you already have the path allocated somewhere since you're making the call. So you could just have a pointer to that path in the error.
That would obviously be very dangerous in C, because then you'd have to be careful not to have your error outlive your allocated path, but in Rust you'd have a lifetime annotation on your Error guaranteeing that your Error does not outlive your allocated path.
This has implications that are obviously undesirable, like prohibiting returning errors borrowing file paths allocated on the stack.
In your particular example you could memcopy the path in the Error, without allocating at all (but you may also want to box the path instead if the path made the enum size too big).
Right making the standard library's error type far less useful if you have to start writing your own error types lol. That's such an obnoxious design. The way it is now you can write programs that return and handle io errors just fine when they don't care about the path or other arguments. Your suggestion would require those programs to make a dedicated error type to unabstract away what is essentially a thin wrapper around errno. The value of a `std::io::Error` is still obviously appealing.
That's a really heavy constraint that doesn't work in practice - errors usually bubble up past the scope of the arguments of whatever failed.
- discard the file path
- allocate
This way, you control the performance/UX trade-off. And it doesn't require much work: it's just a From implementation to add to your error enum.
[1] only higher than the actual owned path actually.
Maybe some day Rust will support multiple versions of the stdlib (in a compatible way, like what's done with editions) but until then we'll have to work with this half-baked corner of the language.
More generally, the interpreter doesn't exist. For a script with a shebang that's whatever is under the shebang. For executables it's whatever is in the PT_INTERP header in the binary (in ELF, or whatever the equivalent is for PE/Mach-O).
For example you might have an ELF binary with PT_INTERP set to /usr/lib/ld-linux.so when it's actually /lib/x86_64-unknown-linux-gnu/ld-linux.so. You'll get a "exec: File not found" error, even if all the files you think you need exist. The loader itself is what's missing.
I've learned to immediately suspect disk exhaustion when I'm experiencing unexplained failures, but in the past it's taken me forever to figure it out.
It also increases the surface area of the API which makes everything around it less portable and may mean it’s awkward to mock in tests.
1. the underlying OS error not containing what
2. some edge cases in which you don't have a what, or at least not a clear one
3. paths, especially absolute paths, always being prone on leaking personal user information
It's basically libc's behavior so any ecosystem that just offers a thin layer on top of libc for file access without thinking about it too much is going to do it this way.