On 2011 Aug 01, at 12:45, Martin Wierschin wrote: > This is even worse than the original problem. Rather than getting an > exception at the time of encoding, now you're silently converting unencodable > objects to strings.
Thank you, Martin. That is correct. > When you unarchive one of those strings, code expecting an instance of > UnencodableFoo will instead have an NSString, the use of which will likely > throw exceptions, eg: when code calls -[UnencodableFoo fooThing] No, it's not likely if UnencodableFoo is *my* code, because I program defensively when dealing with input data such as an archive :) However, I agree that someone else's code might throw an exception. But I wouldn't say it's worse. Compare… • Classic Approach, @try/catch when archiving: Results in an unavoidable exception, which could be caught, but an unavoidable turd left in stderr. • My New Code Code Posted Yesterday: A possible exception, and a possible turd, if I or someone else does not program defensively. Actually, there could be another error in the Classic Approach because – what do you do in the @catch block? Returning nil when an archive was expected may cause an issue. Presently, when I'm archiving an NSError in my @catch block, I replace the object with a string anyhow, which is the same thing I do in my My New Code. Thus, My New Code gives the same result as the Classic Approach, but it does so without raising an exception. So I'm thinking about changing from Classic Approach to My New Code in my next project. I always like to think long and hard before applying a category to NSObject, though. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
