Dan Sugalski wrote:
> Piers Cawley wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
>>> Okay, now that we're well on our way to getting
>>> sub/method/whatever calling down and working, I want to point us
>>> towards what I'm thinking of for exceptions.
>>>
>>> Exception handlers really strike me as anonymous lexically scoped
>>> subroutines that get called with just one parameter--the exception
>>> object. As far as the engine should be concerned, when an
>>> exception is taken we just take a continuation with the address
>>> being the start of the code that handles the exception. They need
>>> to get pushed on the system stack so we can walk up it at runtime
>>> when an exception is called looking for handlers.
>>
>> So, we grab another register for 'current exception continuation'?
>
> Nope. The exception goes onto the control stack. When an exception is
> thrown we walk up the control stack frames until we find an exception
> handler entry, at which point we invoke the continuation associated
> with it, passing in the exception information. (Though we may put the
> exception info out-of-band, since I can see wanting to retain all the
> registers for Truly Clever exception handlers...)
Well, how about we have throwing an exception be similar to resuming a
coroutine?
That is, we save all the context from where the exception was thrown,
and then pass that into the exception handler.
Concievably, we could then examine the exception, and maybe decide that
it was nonfatal, and resume execution from just after the place it was
thrown from.
(Both the classes for exception objects, and for exception handlers,
would then be descendants from class Coroutine)
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
