Re: Debugging insight needed for NSKeyedUnarchiver
Re: Debugging insight needed for NSKeyedUnarchiver
- Subject: Re: Debugging insight needed for NSKeyedUnarchiver
- From: Quincey Morris <email@hidden>
- Date: Mon, 03 Mar 2014 00:48:47 -0800
On Mar 2, 2014, at 23:58 , Graham Cox <email@hidden> wrote:
> the more general question here is whether returning nil from -initWithCoder: should be legitimate or not. After all, it's an init method, and it should follow the rules for all other init methods, shouldn't it?
What are you suggesting that these rules are? AFAIK, there isn’t any “rule” about whether an init method can return nil — it’s part of the API contract in each individual case, isn’t it?
IAC, I don’t think it’s exactly about whether initWithCoder returns nil. Surely it’s about the fact that decoding a NSArray can’t deal with a nil element, since it can’t be inserted into the array. Simply dropping nil elements doesn’t even seem like a possible strategy.
I think you have to assume that it’s your responsibility not to return nil when the object being decoded is part of a collection**. After all, it was certainly non-nil when it was originally archived.
I’d also say there’s a parallel problem when *not* dealing with array elements. If in unarchiving an object (*not* in a collection) you return nil from ‘initWithCoder’ (under the assumption that the object wasn’t nil when archived), you’ll end up with a “hole” in your data model, and you won’t know about it.
Putting those two things together, it seems that simply returning nil from initWithCoder should *never* be done, which is the policy I’ve always followed.
** Which is, in general, unknowable.
_______________________________________________
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