Re: Exceptions and autorelease pools
Re: Exceptions and autorelease pools
- Subject: Re: Exceptions and autorelease pools
- From: Steve Sisak <email@hidden>
- Date: Tue, 06 Dec 2011 21:01:59 -0500
At 3:59 PM -0600 12/6/11, Ken Thomases wrote:
The workaround is necessary because the exception object raised in
allocAndRaise() has been autoreleased. It is no longer owned by
anything and is only still around because the pool containing the
pending release(s) has not been drained. When you drain it, that
executes the pending release(s) and ultimately deallocates it.
That is one of the reasons you are discouraged from
releasing/draining autorelease pools in exception handlers or
@finally blocks.
Ken,
Thanks -- that's something that never occurred to me and makes total
sense given your explanation.
This leads to a follow-on question regarding operations as outlined
in listing 2-3 on:
<http://developer.apple.com/library/ios/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationObjects/OperationObjects.html#//apple_ref/doc/uid/TP40008091-CH101-SW1>
Implementations of [NSOperation main] are required to not throw exceptions.
The boilerplate code given is:
-(void)main {
@try {
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
// Do some work on myData and report the results.
[pool release];
}
@catch(...) {
// Do not rethrow exceptions.
}
}
on my first read, it looked like it leaked and now I know why it
doesn't leak that much. :-)
I realize that this is moot in the case of @autorelease, but in the
context of "best practices" for code that can't depend on ARC, I
still wonder if something like this is a cleaner solution:
-(void)main {
NSAutoreleasePool* pool = nil;
@try {
pool = [[NSAutoreleasePool alloc] init];
// Do some work on myData and report the results.
[pool release];
}
@catch(...) {
// Do not rethrow exceptions.
}
@finally {
[pool drain];
}
}
(Where code which could re-throw could implement the same workaround
an set pool to nil and I assume we should be catching C++ exceptions
as well)
Given that operations have much shorter lifespan than threads, I'd
worry about the leaked NSAutoreleasePool objects in a long-running
application.
Thoughts? Comments? Suggestions?
-Steve
_______________________________________________
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