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.

For a game I don’t think it’s the end of the world, but you could end up in a situation where the first check passed, then you go to use the file and that fails, so you end up having to handle the “can’t use file” case twice anyway. But for something like showing a “Continue” menu item you obviously need to check that there’s an existing save to begin with before loading it.

In general checking first leads to race conditions known as “time-of-check to time-of-use”, the pitfalls of which can vary greatly, but realistically aren’t a problem for a lot of cases.

Well you need to try and catch when getting the file anyways, it’s probably very rare but imagine a scenario of:

• Check if file exists
• user deletes file in between
• (try) opening the file

Or the file could exist, but you don’t have permissions to actually open it.

So a bunch of languages / already have their own “try open file”

General wisdom is that if you can perform some kind of pre-validation action to prevent an exception from occurring, you should do that, rather than expect the exception and handle it, as part of “normal” flow control.

However.

Some types of exceptions, especially when related to itneracting with shared/external systems, cannot be conpletely avoided. Checking for the existence of a file is the textbook example of this. No matter how much you check of the existence of the file, it could technically be deleted or exclusively locked by another process before you get a chance to actually open it.

For all intents and purposes, that’s not really likely to happen, so by all means, check for the file, to keep your code sensible, but make sure you have a general strategy for exception handling in place as well.