The most fundamental feature throwing an exception is that it transfers
program execution from the call site. Allowing the caller to resume
execution at that site is a very dangerous form of action at a distance.
I think you'd be better off a giving the caller an explicit way to
inhibit throwing an exception. That is, use program design rather than
language features to provide this functionality. e.g., a delegate:
$ex = new My::Exception: ...;
die $ex
unless .delegate && .delegate.should_ignore_ex($_, $ex));
Not only is the above pattern clearer to read and less afflicted by
action at a distance, but it provides a wider bidirectional interface.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
> -----Original Message-----
> From: Benjamin Goldberg [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 26, 2003 7:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Exceptions
>
>
> 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;}
>
