Re: NS_HANDLER mystery
Re: NS_HANDLER mystery
- Subject: Re: NS_HANDLER mystery
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 30 Jul 2005 08:54:41 -0700
On Jul 29, 2005, at 5:53 PM, Will Mason wrote:
Why does _NSRemoveHandler() never get called upon reaching
NS_ENDHANDLER? To me the logic would dictate that the structure should
either always be removed from the internal collection, or never.
Having
three cases where it's removed and one case where it isn't just
doesn't
make any sense to me.
Can anyone enlighten me?
Look closely at the macros:
#define NS_DURING { NSHandler2 _localHandler; \
_NSAddHandler2(&_localHandler); \
if (!_NSSETJMP(_localHandler._state, 0)) {
#define NS_HANDLER _NSRemoveHandler2(&_localHandler); } else { \
NSException *localException =
_NSExceptionObjectFromHandler2(&_localHandler);
#define NS_ENDHANDLER localException = nil; /* to avoid compiler
warning */}}
NS_DURING creates *two* scopes; one created by the initial { and the
other created by the { of the IF statement. There is a third scope
created by NS_HANDLER which corresponds to the path of execution of
the else clause of the if statement.
Now, go read the _setjmp man page. It specifically says:
The sigsetjmp(), setjmp(), and _setjmp() functions save their
calling
environment in env. Each of these functions returns 0.
The corresponding longjmp() functions restore the environment
saved by
their most recent respective invocations of the setjmp()
function. They
then return so that program execution continues as if the
corresponding
invocation of the setjmp() call had just returned the value
specified by
val, instead of 0.
In other words, the call _NSSETJMP (which really just calls _setjmp)
returns 0 and the if() statement then enters the body of the second
scope defined by NS_DURING. This scope is the execution path prior
to an exception being raised.
Raising an exception invokes longjmp(), which causes execution to
effectively GOTO the evaluation of the if() statement, only this time
_NSSETJMP() will return a non-zero value, thus causing the else
clause of the NS_DURING's if statment to be executed.
During execution of the else code path, the exception catching scope
has already been destroyed. So, no reason to remove a handler that
has already been removed as a part of raising an exception.
When an exception is raised, the exception handler is consumed
because that particular handler can never be used again as there is
no way for control flow to return to the NS_DURING/NS_HANDLER code
path. Thus, no need to remove the handler and, as a result, no need
to use the NS_*RETURN() functions within the NS_HANDLER/NS_ENDHANDLER
blocks.
b.bum
_______________________________________________
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