Re: Handling errors in -initWithCoder:
Re: Handling errors in -initWithCoder:
- Subject: Re: Handling errors in -initWithCoder:
- From: Quincey Morris <email@hidden>
- Date: Thu, 12 Mar 2009 23:07:22 -0700
On Mar 12, 2009, at 21:05, Graham Cox wrote:
One of my classes can sometimes fail in -initWithCoder: - it relies
on certain resources being available and if it doesn't get them, I
thought I could follow the same pattern as -init and autorelease
self and return nil. When I do this though I get an error from the
dearchiver, like:
*** -[__NSPlaceholderDictionary initWithObjects:forKeys:]: number of
objects (0) not equal to number of keys (298)
This prevents the remainder of the archive from loading, which I
don't want.
What's a good way to handle this? I would prefer that my object
isn't created at all if possible, but that the archive loads what it
can. It's hard to handle this in the class that owns this, because
it's just an array of objects.
I'm thinking I need some post-processing that goes through and weeds
out certain flagged objects, but maybe there's a better way?
If you ever return nil from initWithCoder, it's likely your decoded
data model is screwed beyond the point of recovery, if the failure is
on one of the objects in a collection (which is apparently what's
happening above).
Therefore, if you need to salvage (the rest of) your decoded model,
you can't return nil on failure, but must return a crippled
(==flagged) object, or a proxy object, with just enough behavior to
allow the rest of the model to be unarchived, and deal with the
problem after unarchiving is complete. So, yes, weeding out flagged
objects seems like a good way to do it.
_______________________________________________
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