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 Ccatch we
need to have access to a lot of internal flow data; something like
the stack trace that Ccarp 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 Creturn resumes execution after
the cthrow
$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 Creturn statements,
Cend
moves flow to the end of the current block rather than
returning
from the routine.
$frame-redo
$frame-nextif 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
Cgoto
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
