>> 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.
Right, I was just referring to -[NSMutableData initWithLength:] and other other operations that do/may allocate memory chunks, like -[NSMutableData increaseLengthBy:]. I have no qualms about any +[NSObject alloc] method crashing if memory is exhausted. ~Martin _______________________________________________ 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
