> 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 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]
