Re: Debugging insight needed for NSKeyedUnarchiver
Re: Debugging insight needed for NSKeyedUnarchiver
- Subject: Re: Debugging insight needed for NSKeyedUnarchiver
- From: Graham Cox <email@hidden>
- Date: Tue, 04 Mar 2014 09:42:30 +1100
On 4 Mar 2014, at 5:30 am, Quincey Morris <email@hidden> wrote:
> t can certainly be true that for some unarchived arrays, dropping un-unarchivable elements is appropriate. You’re currently dealing with such a case. That’s a valid strategy for your app, but it’s not a valid strategy for the frameworks unarchiver classes:
>
> 1. It’s not true *in general* that an array is a list of objects whose index in the array is insignificant. *In general* it must be assumed that the index matters, so dropping elements is not a possible *general* strategy.
We can agree on this point - I'm sure *in general* that keeping an object at its original index is desirable, even though in my particular case it's not important. I could settle for that. What's disagreeable is that at the moment it keeps an arbitrary number of array items and discards an arbitrary number, based on where in the array an object failed to dearchive.
> 3. Unarchiving contains no standard error reporting mechanism. If it were to do as you say you wish, there’d be no indication that anything was wrong. (As it is, there’s no indication that anything was wrong with the array. *That* seems like a bug — it should probably throw an exception.)
Definitely. If the rules are that -initWithCoder: *must* return an object and that object *must* be the same one that was created by the internal alloc and not some other, then that needs to be spelt out in the documentation, as it is contrary to other forms of -init, and further, NSKeyedArchiver should enforce it by throwing an exception if the pointer returned by initWithCoder: is not the same as the one returned by alloc.
If NSKeyedUnarchiver was doing this, I'd have discovered my bug immediately, instead of taking three very hard and wearisome days to track it down.
Radar: 16215603
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden