> The fact that these methods throw exceptions if their input data cannot be > processed is very uncharacteristic of the Cocoa frameworks.
Now it is. Back when NSCoding et al were written, possibly not. Opinions on the use of exceptions vs other methods have waxed and waned over the years. Only recently has there been a comparatively strong push towards NSError. There are many APIs which are transitioning to NSError. NSCoding and friends may also transition in time (or be replaced entirely...). > When invoking -archivedDataWithRootObject: on, say, dictionary, finding an > un-encodeable object buried somewhere in the dictionary would seem to be > quite common. Similarly, when invoking -unarchiveObjectWithFile:, no > programmer can guarantee what may be found on the filesystem. And this is one of several concerns with the NSCoding system. It may be that the reason these classes haven't been updated is because there's consternation over the value of such an update. Some people consider NSCoding intractably insecure and ergo unsuitable for use in pretty much anything. Others take issue with it for varied other reasons. I personally like it, but it's not flawless. I wouldn't stress too much over it, in any case. Sooner or later a change will occur. 'til then, follow the best practices to date. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
