An invalid property list
If you work on an [added: a document-based] app that uses a plist-based format, you should test your plist-reading code to see how it handles an invalid (e.g., eaten by the user’s dog) plist. Here’s one:
<plist>
<qux></qux>
</plist>
The binary plist parser won’t even touch it because it doesn’t have the bplist header, the XML parser will choke on it because it contains an element that it doesn’t recognize, and the OpenStep parser will choke on it because the first line doesn’t end with a semicolon or backslash.
When you feed this to your app, your app should present an error message. Anything else is a bug. (UPDATE 2007-10-02: OK, maybe not. There’s at least one circumstance where you can ignore it, as pointed out in the comments. I still think I’m right in most circumstances, just clearly not all.)
October 1st, 2007 at 17:37:00
“Anything else is a bug.”
Man, talk about a sweeping statement. It’s an easy exercise to come up with dozens of situations where that statement wouldn’t be true.
October 1st, 2007 at 17:59:42
Perhaps I should specify that I mean a document-based app reading its documents. I’ll update the post. ☺
Given this new constraint, what’s a situation where a document-based app would be reading a document in its plist-based format, and would find that the document is not a valid plist, and should do something other than present an error?
October 1st, 2007 at 22:55:36
Ooh, I know! It could be a bundled document (or archive) in which the plist isn’t critical.
October 2nd, 2007 at 05:50:23
Jens Ayton: Ah, good point.
You can tell I don’t ordinarily think about bundle-based document formats—or, for that matter, implement them. ☺