I'm trying to figure out what information we have in userland for knowing when es3 disk I/O fails.
We of course want to prevent player data corruption, unlikely as it may be.
ES3 provides us with CreateBackup/RestoreBackup to help with this, but how can we tell when we need to restore from a backup?
The specific scenarios I have in mind are:
- On app startup (expect to find a functional save file, but it's corrupt in some way)
- On sync/shutdown (sync failed)
Exceptions I could use that I've been able to find in the documentation:
-ES3.Load()/LoadInto(): "a KeyNotFoundException or FileNotFoundException will be thrown if the data does not exist"
Other behavior we could perhaps use to check:
-ES3.KeyExists(): false if it doesn't exist, but does a save delete-then-write, or does it just overwrite? Might keys exist even if the sync failed?
-ES3.FileExists(): false if it doesn't, but can a failed sync trigger this?
-ES3.RestoreBackup(): returns true if it restored, false if no backup found
Am I missing something? Does Sync() throw exceptions?
With the above, I feel like I need to write some sort of check into the code (value validation) or the files (CRC-style) to ensure that they've survived save/load correctly.
Is there a better way?
Hypothetical Sync() exceptions
Re: Hypothetical Sync() exceptions
Hi there,
Generally if any exception is thrown at runtime then this is an indication that something went wrong.
However, with regards to I/O exceptions, we simply use the exceptions thrown by .NET. This throws a System.IOException, but it could also throw an EndOfStreamException, IndexOutOfRangeException, NullReferenceException or CryptographicException depending on what has gone wrong (for example, if there is parseable data).
All the best,
Joel
Generally if any exception is thrown at runtime then this is an indication that something went wrong.
However, with regards to I/O exceptions, we simply use the exceptions thrown by .NET. This throws a System.IOException, but it could also throw an EndOfStreamException, IndexOutOfRangeException, NullReferenceException or CryptographicException depending on what has gone wrong (for example, if there is parseable data).
All the best,
Joel