On Sun, Jul 09, 2006 at 06:27:13PM -0400, Bob Rogers wrote:
> I have a question about C<handled>. r13214 adds item 2 in the following
> snippet from the current revision:
>
> When the C<handled> opcode is called:
>
> =item 1
> Pop and destroy the exception record.
>
> =item 2
> If there was a continuation in the exception record, invoke the
> continuation.
I hadn't looked at r13214 yet, but I agree that changes is problematic. It
misses the implications of the continuation being passed as a parameter and
the existence of the C<handled> opcode: It is to give the handler complete
freedom as to where to transfer control after handling the exception.
RATIONALE:
What the programmer may consider a warning may become an error in the end.
Consider the Perl equivalent of gcc's -Werror. So it's not OK for throwcc
force continued execution at any given continuation when handling is done.
Also consider that there is little value in a C<handled> opcode that
transfers control. If it were OK for Parrot to force continued execution in
a particular place, then the handler could just return the values that are
currently the parameters of C<handled>, and Parrot would take it from there.
These are the use cases I had in mind for exception handler code:
(1) "I can handle it"
[a] execute C<handled>
[b] invoke some continuation, perhaps the one we got as a parameter,
perhaps a different one
(2) "I can't handle it"
just return
So in short I think C<handled> should go back to merely clearing the
"exception in progress" but not transfer control.
--
Chip Salzenberg <[EMAIL PROTECTED]>
