Re: catches in @catches (was: NSError: why returned directly?)
Re: catches in @catches (was: NSError: why returned directly?)
- Subject: Re: catches in @catches (was: NSError: why returned directly?)
- From: Chris Hanson <email@hidden>
- Date: Wed, 26 Apr 2006 12:24:19 -0700
On Apr 26, 2006, at 12:03 PM, Ondra Cada wrote:
(i) overReleaseException *does not* overrelease anything
The code
-(void)overReleaseException { // in my opinion named quite improperly
NSAutoreleasePool *pool=[[NSAutoreleasePool alloc] init];
[self doSomething]; // may--just as any other method--raise
[pool release];
}
is perfectly right and does not overrelease anything.
[snip]
Am I wrong? If so, why?
It doesn't over-release anything in itself, but depending upon how
the code that calls it is written, it can wind up delivering a zombie
exception - an exception that has been released before it was
delivered. As I said in the post, one way to avoid this is to avoid
releasing autorelease pools in @finally blocks.
Another way to avoid this is to, if you do release an autorelease
pool in a @finally block, to be sure you catch and "promote" any
exceptions that have occurred to any outer autorelease pool. As
you've noticed, changing -overReleaseException can't address the
issu; fixing the caller that introduces its own pool and releases it
in a @finally is the solution.
Often framework-level code should try very hard to avoid "polluting"
the autorelease pool of calling code. If framework code can't avoid
using autorelease, it should generally do so in an inner autorelease
pool that gets released before returning to the caller. There are
also situations where one might write code like this to try to keep
an application's high-water mark from growing significantly. These
are the main places where a developer would want to use this pattern
-- it continues to ensure that the pools are released at the right
time, while also making sure that exceptions (and errors) are
propagated correctly.
-- Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden