<[EMAIL PROTECTED]> wrote:
+Since the structure and content of a compiled subroutine are fixed at
compile
+time, it would be wasteful use the dynamic execution of opcodes at
runtime to
+keep track of meta-information about that structure -- I<including the
spans
+of opcodes that the programmer expects to throw exceptions, and how the
+programmer wants to handle them.>
+
$dotnetometer++
+=item B<.begin_eh I<LABEL>>
+
+A C<.begin_eh> directive marks the beginning of a span of opcodes which
the
+programmer expects to throw an exception. If an exception occurs in the
+execution of the given opcode span, Parrot will transfer control to
I<LABEL>.
+
+[XXX - Is a label a good approach? Treating exception handlers as label
jumps
+rather than full subroutines may be error-prone, but having the lexical
stack
+conveniently at hand is worth a lot.]
+
IMHO, the label approach is the right thing. But it'd be nice to be
consistent...
+=item B<pushaction I<SUBPMC>>
+
+C<pushaction> pushes a subroutine object onto the control stack. If the
+control stack is unwound due to an exception (or C<popmark>, or
subroutine
+return), the subroutine is invoked with an integer argument: C<0> means a
+normal return is in progress; C<1> means the stack is unwinding due to an
+exception.
+
I guess this is suitable for implementing "finally" handlers, but I've not
been able to use it to implement the .Net exception system's finally
handlers. See the exceptions section in my write-up for how I do this now.
But the main issue (other than it being a pain to have to generate another
sub after the current one to contain the handlers) is lack of access to the
locals and parameters.
I guess maybe it *could* work if I make the finally handler have
:outer(parent_sub), but even if that does work (does it?) I'd have to make
all my local variables lexicals, creating a lexpad etc, when actually I
needn't otherwise to that. (Plus the performance issues, since .lex's can
only be PREGs).
Of course, the trick I do now works, and hey I've implemented it now so I
don't really mind if there's no nicer support for what I want to do. But
the next person who wants to compile another langauge that needs something
like this might mind more. ;-)
Hope this is another data point that helps get a good final solution,
anyway. (And sorry if it's incoherent. It's kinda late here and I'm full
of coldy-flu-ish nastiness.)
Thanks,
Jonathan
