I had been thinking of some special goto labels, things like
BEGINNING and END which would signify the beginning and end of the
block enclosing the throw; perhaps every SCOPE object could have
these labels refered to in terms of them. inside a C<catch> we
need to have access to a lot of internal flow data; something like
the stack trace that C<carp> provides. If there is a way to
have program flow procede to the beginning, end, or current execution
point in any stack frame could be some methods on the STACK_FRAME
object like, start(), return(), resume(), end()
$frame->start() this would start over at the beginning of
$frame, it would be what is implicitly
called when the language enters a frame.
After defining it. So you can start again
with different parameters by altering
$$frame->_[2] for instance.
$frame->return(BLOCK) this moves flow of control to the point
where $frame was called from, as if $frame
had returned with the value of the expression
in BLOCK. This is the OO version of "return" which
of course normally operates w/in the current block.
so an unqualified C<return> resumes execution after
the c<throw>
$frame->resume(BLOCK) like return, but restarts $frame at the point it is
waiting for a return value, with the BLOCK providing
the return value.
$frame->last(BLOCK) very similar to return, control goes to the end of the
frame. The difference is, inside nested blocks inside
called blocks that may contain C<return> statements,
C<end>
moves flow to the end of the current block rather than
returning
from the routine.
$frame->redo
$frame->next if loop blocks become FRAME objects, these will then be
possible too, unless they get compiled away, in which
case
they won't, I don't know -- see `perldoc -f redo`
$frame->eval(BLOCK) evaluates BLOCK in the context of $frame, can include
C<goto>
or any other flow-control directives, in which case
this
will not return.
Glenn Linderman wrote:
>
> "David L. Nicol" wrote:
>
> > What I was suggesting was, if you want to overload the autoloading
> > of something, it could be done with "catch" instead of rewriting
> > the ::OVERLOAD procedure, for that module.
> >
> > "method not loaded" becomes an exception which is thrown, rather
> > than "AUTOLOADING" being its completely separate deal. OO allows
> > the combining og procedures that have things in common. AUTOLOAD
> > of a METHOD-NOT-FOUND is an excellent example of a genuine case
> > of an exception (no method!) and a handler (autoload mechanism.)
> >
> > It makes these file-not-found things look like contrived crap they are.
>
> But none of the currently proposed exception handling/reporting mechanisms
> support any sort of "resume" or "retry" functionality... they just
> extricate you from the current code path, and take you to a different place
> in some equal or higher code path. Now it would be possible to manually
> code the retry in some circumstances, for some errors. However due to the
> potential for side effects in the invoking expression, it may not be
> possible to do that in general, without language support for "resume" or
> "retry" functionality.
>
> --
> Glenn
> =====
> There are two kinds of people, those
> who finish what they start, and so
> on... -- Robert Byrne
>
> _____NetZero Free Internet Access and Email______
> http://www.netzero.net/download/index.html
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Useless use of a void in constant context
