Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: "Clark S. Cox III" <email@hidden>
- Date: Wed, 21 May 2003 09:39:24 -0400
On Wednesday, May 21, 2003, at 09:24 US/Eastern, Marcel Weiher wrote:
I don't think so:
-(void)drawMyObject
{
[gc saveGraphicsContext];
NS_DURING
[self doStuffThatMightThrowExceptions];
NS_HANDLER
//-- exception we want to handle locally
NS_ENDHANDLER
[gc restoreGraphicsContext];
}
What happens if an exception is thrown that we *don't* want to handle
locally? We have to re-raise it, but before doing so, we have to
remember to restore the context..
-(void)drawMyObject
{
[gc saveGraphicsContext];
NS_DURING
[self doStuffThatMightThrowExceptions];
NS_HANDLER
//-- exception we want to handle locally
if(we don't want to handle locally)
{
[gc restoreGraphicsContext];
//re-raise the exception
}
NS_ENDHANDLER
[gc restoreGraphicsContext];
}
As evidenced by the fact that you left out a call [gc
restoreGraphicsContext], shows the usefulness of doing this
automatically.
Not in the least bit. I said it was *one* alternative, well aware
that there were others:
-(void)drawMyObject
{
id possibleException=nil;
[gc saveGraphicsContext];
NS_DURING
[self doStuffThatMightThrowExceptions];
NS_HANDLER
//-- exception we want to handle locally
possibleException=localException;
NS_ENDHANDLER
[gc restoreGraphicsContext];
[possibleException raise];
}
Still just one save/restore. Objects are good.
(1) Because it has nothing to do with the stack-frame (2) because
you are achieving the effect by *declaring a local variable*.
Notice the part about "declaring"...
Actually I'm "defining" a local variable,
Gosh, this sure looks like a declaration to me, and just strengthens
my point. How can I tell the difference by looking at the code? How
is the code intention-revealing?
void foo()
{
//These are all defining local variables:
int i;
float f;
MyClass c;
}
//These are declaring variables:
extern int i;
extern float f
extern MyClass c;
and a defining local variable is nothing more than attaching some
bit of data to the local stack frame, so it has *everything* to do
with the local stack frame.
Exactly! *Declaring* the local variable has something to do with the
*local stack frame*. It has NOTHING whatsoever to do with modifying
*global* state.
It does, if I want to ensure that the global state will be restored
upon exiting the local stack frame. That is the whole point ot such a
class: to tie the restoration of the global state, or the release of
some resource to the local stack frame. It is simply good practice to
make sure that a function will clean up after itself in all foreseeable
cases.
On the other hand, the global graphics state has nothing to do with
the local stack-frame.
That is why such a class is so useful.
--
http://homepage.mac.com/clarkcox3/
email@hidden
Clark S. Cox, III
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.