Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
- Subject: Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
- From: email@hidden
- Date: Fri, 29 Jul 2011 18:48:24 -0700
> Looking back at code I wrote years ago, I see that I usually did things like
> @try {
> someObject = [NSKeyedUnarchiver unarchiveObjectWithData:someData];
> } @catch (id exception) {
> someObject = nil; // or some other reasonable default state
> // mark someData as being corrupted to avoid its reuse
> }
> and this works well in my (admittedly not overly thorough) testing. I do the same when reading in nib files, image resources, etc..
Interestingly there are some exceptions that will not be caught by the above. I can't remember the details, though, as it was years ago when I was wrangling with them. I never came up with a better approach, though, I remember that much.
> However, I've also seen cautions that after throwing _any_ exception whatsoever we should terminate the application as soon as possible.
These days especially, exceptions in "Cocoa" are generally considered crash-worthy, yes. In the sense that you shouldn't try to catch them unequivocally; only in specific cases where it's clearly reasonable and there's no alternative - the above being such a case.
> Granted that NSKeyedUnarchiver might have left some memory leaks or partially uninitialized objects somewhere, but unarchiving an invalid object should happen rarely if at all... and ordinarily my own code should never get pointers to such objects, anyway.
Indeed there may be memory leaks, but that's a relatively benign side effect. The security issues I alluded to earlier are a much greater concern in any case.
>
_______________________________________________
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