Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
- Subject: Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
- From: Quincey Morris <email@hidden>
- Date: Thu, 13 Aug 2009 10:05:38 -0700
On Aug 13, 2009, at 03:45, Georg C. Brückmann wrote:
Consider NSURLConnection’s -connectionDidFinishLoading: delegate
method:
- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
// Do stuff
[myReferenceToTheConnection release];
myReferenceToTheConnection = nil;
}
Now, in the case of NSURLConnection there’s no need to ensure the
connection object remains valid until the current autorelease pool
gets drained (aka at the end of the current run loop cycle). But one
doesn’t always know how a specific class is implemented, and in that
case autoreleasing can help you prevent malloc errors.
I admit these are probably edge cases, but I’ve stumpled upon them.
So while you may consider this overly cautious, writing such a macro
takes about ten seconds – time that is easily saved when using the
macro as it saves you one line of code each time you use it.
Pragmatically, autoreleasing 'myReferenceToTheConnection' might be a
reasonable solution to a (potential) problem.
In fact, relinquishing ownership of the connection during this method
is simply a bug. If you're its owner, you're responsible for
preventing it from being deallocated while it's still alive -- and
it's still alive.
In this case, you're pretty sure that autoreleasing it keeps it from
being deallocated long enough for its lifetime to end, but that's not
a safe general assumption. What if the object you're releasing has a
pending error message it's going to display after a timer expires
(i.e. after the autorelease pool has been drained)?
So, in such cases, you have an object lifetime issue that must be
solved on a case by case basis. Sometimes -- maybe most times --
autoreleasing might be an answer, but I don't think that recommending
the use of 'autorelease' over 'release' *as a routine safety
precaution* is a viable position to take.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden