Hi Günther,
Non-local returns can indeed be implemented in terms of exceptions -
they are. LanguageKit uses the standard exception handling mechanism
for them, but a different personality function. They should therefore
not interfere with Objective-C (or C++) exceptions.
When the stack is unwound through Objective-C code compiled with -
fnative-exceptions, anything in a @finally() block ought to be called
as the stack unwinds. If it isn't, it's a bug.
If you are using setjmp()/longjmp() exceptions, then I have no idea
what will happen, but it's probably going to be a mess. The old style
exceptions do not have any equivalent of @finally, they are
responsible for making sure that everything is autoreleased as soon as
it is used.
The NS_VALUERETURN() thing is used with sj/lj exceptions to pop the
current jump buffer off the exception stack. This will not be called
when you unwind via a Smalltalk non-local return, nor when you throw a
C++/Ada/whatever exception through an Objective-C sj/lj NS_DURING block
Your example should work. You are not correct in your assertion that
NS_VALUERETURN is needed in NS_HANDLER blocks - using it here is
incorrect and may corrupt the exception handler stack. By the time
the do: block is run, the jump buffer should have already been popped
from the stack. You will, however, encounter a problem if you do
something like this:
test [
[
self mayThrowException.
^ true.
] onException: 'NSSurpriseException' do: [
^ false "Non-local return!"
]
Here, the non-local true return unwinds through the NS_DURING block in
BlockClosure. If native exceptions are not supported then the
exception handler destination will not be popped off the stack and the
next exception may go to the wrong place, or may cause a warning to be
NSLog'd, depending on the state of the stack when the next exception
is thrown.
David
On 10 Feb 2009, at 09:14, Günther Noack wrote:
>
> Hi,
>
> I post this to the list because I think it may be a good idea for
> documentation reasons.
>
> In the past days I've been thinking about how the whole stack-
> unwinding code can be tested, like -[NSObject release]ing objects when
> exceptions or non-local returns fly by over the stack locations of
> their references. The more I think about it, the more I come to the
> conclusion that a formal model of it may be a good idea.
>
> An interesting thing I noticed was: Exception handling mechanisms can
> be implemented using non-local returns. Non-local returns can be
> implemented using an existing exception handling mechanism.
>
> Because of that observation, I started to wonder how well the LK non-
> local returns play together with the stack unwinding done in
> Objective-
> C exception handling, particularly in cases like these:
>
> test [
> [
> self mayThrowException
> ] onException: 'NSSurpriseException' do: [
> ^ false "Non-local return!"
> ]
> ^ true
> ]
>
> The point here is this: Objective-C exception handling requires you to
> use NS_VALUERETURN inside of Try- and/or Catch-Blocks. The
> onException:do: implementation does exactly that with the handler
> block's return value. However, by using non-local returns, this can be
> circumvented.
>
> I'd like to write a test to check that, but I currently really don't
> know how to check for incorrect stack unwinding. Does anyone of you
> know this?
>
> Best regards,
> Günther
>
>
> _______________________________________________
> Etoile-dev mailing list
> [email protected]
> https://mail.gna.org/listinfo/etoile-dev
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
