Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: Marcel Weiher <email@hidden>
- Date: Wed, 21 May 2003 14:13:42 +0200
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];
}
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 mack 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"...
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
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.