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:09:16 -0400
On Wednesday, May 21, 2003, at 08:13 US/Eastern, Marcel Weiher wrote:
On Wednesday, May 21, 2003, at 01:56 Uhr, Clark S. Cox III wrote:
On Wednesday, May 21, 2003, at 04:02 US/Eastern, Marcel Weiher wrote:
<CodingHorror>
</CodingHorror>
The only real alternative:
- (void)drawMyObject
{
[gc saveGraphicsContext];
try
{
DoSomeStuffWhichMightThrowExceptions();
[gc restoreGraphicsContext];
}
catch(const someExceptionIWantToHandleLocally &)
{
[gc restoreGraphicsContext];
}
catch(...)
{
[gc restoreGraphicsContext];
throw;
}
}
Note that you have to have three calls to [gc
restoreGraphicsContext]; (actually one plus one per exception handler
and one per return statement).
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.
This certainly looks like an alternative to me, though you might have
objections to it. I also think that the 'real' problem here is that
the save/restore mechanism doesn't have automatic nesting like
autorelease-pools, where a missed pool will simply be picked up by a
later pool. Assuming you use exceptions for *exceptional* situations
and not to implement control-flow, that would handle most needs quite
nicely.
Furthermore, if this sort of thing were to be needed with any
frequency, I might very well wrap it up in a higher order message, so
it looks like this:
[[self inProtectedGstate] drawMyObject];
This has the same advantage of encapsulating the save/restore
mechanism, but without obscuring the code. In fact, it clearly
indicates in the code what will happen.
[..]
This type of stack-based utility class is quite logical and straight
forward.
I object to calling this sort of thing "straight forward". It is
absolutely obscure.
You want to make some change, but only have it persist for the
current stack frame, what better way than to tie the actually
setting/resetting of that state to entering and leaving the stack
frame?
(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, 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.
Enter stack frame --> construct local variables
Exit stack frame --> destroy local variables
If I want to put code in a single place that will ensure that it get
called when leaving the current stack frame, the destructor is a
perfect place to do so.
--
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.