For context, I am trying to do a save system for a game.
If you’re already using an existing engine this is already baked in.
But a new engine I would suggest confirming that the file is there and that there is no handles holding it.
I would explicitly check in this case - but this might not be the right way if you were doing something else, like updating a row in a table millions of times a second. It’s always context dependent.
I’m sorry that you’re getting differing answers to your question, but I strongly feel that you should attempt to load it and handle the error if it does not exist.
The reason is because if you rely on checking first, it’s always possible that something could happen to the file between when you check and when you perform the load. Plus, you should be prepared to handle the exceptional condition in general. What if you have something strange like the file exists but you don’t have permission to read it?
Because you should implement handling for those errors anyway, you might as well use it as your main means of processing a file that doesn’t exist. That is my suggestion. You can still check before trying to load, but you need to handle the case of the file not existing when you’re loading.
Generally speaking, there is a race condition lurking where the OS may do whatever to your file you just checked, rendering the check strictly obsolete the moment you get the result. This isn’t typical, but possible, and a lovely old-school security vulnerability class. :)
A more practical argument is that you’re going to handle any errors your open() may throw, anyway, and therefore it’s simply redundant to check for file existence explicitly beforehand.
Under specific circumstances, you may want to do explicit, very specific tests for more detailed error reporting than “error opening file!”, for example “save file is corrupted” if it’s too short or zero-length, or “save file directory is gone. What the hell, dude? Recreating it, but stop fiddling with my files!”
This is easy to overengineer. Best is to get into the very sensible habit of always checking for errors or exceptions returned by your calls, and this will become a non-issue.
In this particular use-case of save file loading, you might implement displaying a listing of save files in a directory with opendir/readdir or FindFirstFile/FindNextFile and its ilk, to offer a list of files to load, which doubles as a crude existence test already. Many ways lead away from Rome. If you’re considering loading an autosave and offer a “Continue” button or something, a cheap existence test would work very well to decide if that button needs to be displayed in the first place, but doesn’t free you from handling any open() errors later. You could also open() and validate an autosave directly, and when/if the user decides to “Continue”, use the already reserved file descriptor and maybe even the preloaded save data to quickly jump into the game.
If you want a simple answer: Do not introduce race conditions. Always acquire a lock for a shared resource before doing anything with it.
This depends quite a bit on your language and framework/filesystem-library. Could you add what those are?
Do you mean moonshine_save? Does it even provide an API for loading that doesn’t return a Result with a possible LoadError?
Rust doesn’t generally “throw” errors, it returns them; and generally, function APIs will guide you in the right direction. You generally should not use unwrap() or expect() in your finished code (though the unwrap_or... variants are fine), which means that you must handle all errors the API can return programmatically (possibly just by propagating with ?, if you will instead be handling the error in the caller).
