On Sep 23, 2011, at 2:40 PM, Martin Wierschin wrote: > I think crashing is a fine behavior when one is really out of memory (eg: > it's not even possible to alloc a single vanilla NSObject), or when using > Cocoa classes that aren't memory allocators (pretty much everything besides > NSData). But in this case, where he's requesting big chunks (10MB at a time), > it would be nice if NSMutableData would return nil from its initializers to > signal that. > > I know it's good to be consistent across the framework, and you really don't > want to have to test every NSData/NSMutableData operation that could fail. > But if you expect/know you're requesting a larger allocation, it would be > nice if there were methods that allowed for error checking instead of > undefined behavior (crashing, exceptions, logging, etc).
Well, I’m not sure I’d technically consider that being inconsistent across the framework in the first place, since those are two different cases — if you’re so badly out of memory that you can’t even allocate an NSObject, then it’s going to be the +alloc method that fails. However, if it’s just allocating a big chunk that’s failing, then +[NSMutableData alloc] is going to work fine, and it’s going to be one of the -initWith... methods that will actually fail. What does +[NSObject alloc] do when the process is out of memory, anyway? Does it throw an exception, or just return nil? The docs don’t seem to mention either way. Charles_______________________________________________ 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
