I received a reply off-list suggesting that I file a bug. And I'll certainly
do that, but before I do that I'd like to confirm that I'm not overlooking
something obvious.
The fact that these methods throw exceptions if their input data cannot be
processed is very uncharacteristic of the Cocoa frameworks. 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.
Has anyone else ever noticed that these methods are exceptionally lame in their
lack of error-handling capability? Is there something about the (un)archiving
process which makes it particularly inefficient to detect and handle errors?
Jerry
On 2011 Jul 28, at 23:24, Jerry Krinock wrote:
> With each major update of Mac OS X, Apple updates more classes to return
> proper NSErrors, deprecating methods which either don't give errors or give
> outmoded error representations.
>
> But what about NSKeyedArchiver and NSKeyedUnarchiver, in particular these
> methods…
>
> +[NSKeyedArchiver archivedDataWithRootObject:]
> +[NSKeyedUnarchiver unarchiveObjectWithFile:]
>
> -unarchiveObjectWithFile: takes a file, for heaven's sake. If someone has
> messed with the file, eek, it raises an exception. I generally enclose these
> methods in @try{} to avoid that. Very primitive!
>
> Does anyone know why these methods not marked for deprecation? Is there a
> reason why we don't we have 21st-century archive/unarchive methods that
> return errors instead of raise exceptions?
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
