Working on the same assignment as you're. I'd probably use this magic value to validate that the file I'm opening is a valid database file. As in if the value is non-numeric, I'd probably throw an exception & stop.
Well, I've been thinking about the file validation, you know, I was giving some thought to the problem of determining if the file is corrupted.
I am not sure that I should do that, because I could suppose the file is never corrupted and I could document it that way in the design choices file. What do you say to that, pal?
On the other hand I could use this "magic cookie" as validation mechanism, but that does not warrant that the file is not corrupted at all.
Are you taking any particular strategy to validate the well-formedness of your file?
For instance, while reading metadata:
Validate file size (Because the file has to be at least big enough to hold the magic cookie and an integer containing the number of fields equal to 0 if the file is empty, and that'll be at least 6 bytes).
Validate that the number of fields be a positive number integer.
Validate that fields names are compliant with the naming conventions of identifiers
Validate that field sizes are positive numbers
If I find unexpected values in any of this validations I will have to throw some sort of UnknowFileFormatException.
What do you think, people?
Good luck to you too, Chengwei. Thanks again for your feedback.
Having gotten past all those checks you mentioned, you can also do a validation on the file size itself: you should know the size of the meta-data (that is a constant), you should be able to calculate the length of the schema, and from that you can determine the size of a record. Subtract the meta-data size and the schema size from the size of the file, and the remainder should be an exact multiple of the the record size.