On Dec 5, 7:29 am, [EMAIL PROTECTED] (Patrick R .
Michaud) wrote:
> # New Ticket Created by Patrick R. Michaud
> # Please include the string: [perl #48152]
> # in the subject line of all future correspondence about this issue.
> # <URL:http://rt.perl.org/rt3/Ticket/Display.html?id=48152>
>
> Many exception handlers in the repository use a ".get_results"
> directive to obtain the thrown exception object. This directive
> doesn't seem to be documented anywhere, except in the (highly
> outdated) "compiler_faq.pod" document.
>
> TODO: (1) adopt .get_results and document it, or (2) deprecate it
> and identify what is to be used in its place.
>
> Pm
I think .get_results is syntactic sugar for the get_results op, but
allowing for local variables + flags instead of the PASM-style
<get_results "0,0", a, b>
In normal cases, get_results is used to retrieve the return values of
a call, which seems a bit strange (not intuitive) as you don't call
the exception (but I don't know the implementation details)
It seems to me you'd want to retrieve the parameters; in Java one
would write it like so:
try {
// do something kinky
}
catch (Exception e) {
}
In the catch block, e is the "parameter" with which the catch block is
"invoked" (it's not really invoked I think, but that's the metaphor
here, I think Parrot allows for both labels and subs these days, no?).
So, then I would think, wouldn't it be more intuitive to write it like
so:
.sub main
push_eh handler
# do something kinky
handler:
.local pmc exc
.get_params exc
# handle exc
.end
I'm not sure how many params could be passed, but if any number, then
the :slurpy and other flags could be used.
One could even consider writing:
.sub main
...
handler:
.param pmc exc
...
.end
which is shorter than ".local pmc exc; .get_params exc".
my 2c,
kjs
