>> Exceeding the available memory of the garbage collector should not crash, >> instead your allocations should fail. > > When memory allocations fail, apps crash. Like it or not, that's just the way > it is. Not sure what the alternative would be - Changing all (!) of our code > to handle out-of-memory errors at every method / function call? And then if > you were to catch such an error, having to handle it without being able to > allocate memory?
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). ~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
