Furthermore, and this is completely up to you, but if you don't want anyone cheating, I'd suggest saving the file in a binary format rather than text. It won't completely stop people from cheating but it won't make it as trivial for someone to open the save file in a text editor and just start messing around. They'd have to use a hex editor and have at least some idea of how your code works to know what data affects what.
Plus, you get to save a lot of space by using binary. Say the user has a score value of 255 - saving that in text takes up three bytes in the file whereas saving it in binary would only take up one byte (one byte = 8 binary digits/bits, 255 is the max 8-bit unsigned integer.) Of course, if you're treating the score as an
int, it'll take up 4 bytes in the file no matter if the score is 0 or 2 billion, but, storing a large number like "2147000000" in text takes up A LOT more bytes in the file than it would in binary.
I know that wasn't really related to the question but... just thought I'd give some extra advice on how to improve and optimize your save format. That's just my opinion though. My game stores its save data in a NoSQL database, but...that's a bit overkill for this kind of data.
Edit: I also noticed in your code that you're catching all exceptions that get thrown when accessing your save file. You probably don't want to do that in case you end up introducing a bug into the code and not realizing it, which could potentially end up causing you hours and hours of headaches trying to figure out why your game isn't saving when it's told to, despite no apparent errors being encountered. The only time you should legitimately see an Exception get thrown by your save system (ignoring any accidental bugs in the code) would be if the user was tampering with the file and screwed up the formatting. In that case, it's on them if the game crashes when reading the save file. Though you'd probably catch any exceptions thrown by the save function itself (i.e:
//Alert the player that their save file is corrupted, then start a fresh game.
so that if there IS an issue loading the save file, the user is alerted that the save file is corrupt (and you are given a stack trace and a description of the issue in the Console if you're running a DEBUG build) and the game can recover and start fresh as if there's no save file there. You shouldn't have to do this when writing to the save file though, as you're overwriting what was previously there with properly formatted data.