[svn:parrot-pdd] r13214 - in trunk: . docs/pdds
all...@cvs.perl.org
Date: Sat Jul 8 16:48:27 2006
New Revision: 13214
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
r201@lilal: allison | 2006-07-08 16:37:32 -0700
[pdd23]: Answered some questions and refined process descriptions.
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==============================================================================
--- trunk/docs/pdds/pdd23_exceptions.pod (original)
+++ trunk/docs/pdds/pdd23_exceptions.pod Sat Jul 8 16:48:27 2006
@@ -60,9 +60,9 @@
=item B<pop_eh>
-Pop the most recently pushed exception handler off the control stack.
+Pop the most recently pushed exception handler off the exception handler stack.
-{{ TODO: Provide control stack introspection. }}
+{{ TODO: Provide exception handler stack introspection. }}
=item B<throw I<EXCEPTION>>
@@ -96,13 +96,9 @@
Exception handlers can resume execution immediately after the C<throwcc>
opcode by executing the C<handled> opcode, and then invoking the given
continuation which they receive as a parameter. That continuation must be
-invoked with no parameters; in other words, C<throwcc> may I<not> return a
+invoked with no parameters; in other words, C<throwcc> never returns a
value.
-{{ TODO: Resuming immediately after the C<throw> opcode isn't quite
-flexible enough. Perl 6, for example, resumes control flow after the end
-of the block in which the exception was thrown. }}
-
=item B<die [ I<MESSAGE> ]>
The C<die> opcode throws an exception of type C<exception;death> with a
@@ -110,8 +106,8 @@
payload is a C<String> PMC containing I<MESSAGE>; if I<MESSAGE> is a PMC, it
is used directly as the exception payload.
-{{ TODO: What is the default when no I<MESSAGE> is given? Something like
-"Fatal exception at LINE in FILE." followed by a backtrace. }}
+The default when no I<MESSAGE> is given is "Fatal exception at LINE in
+FILE." followed by a backtrace.
If this exception is not handled, it results in Parrot returning an error
indication and the stringification of I<MESSAGE> to its embedding environment.
@@ -143,47 +139,51 @@
=over
=item 1
-Find the topmost exception handler
+Find the topmost exception handler.
=item 2
-Push an exception record somewhere, presumably on the control stack.
-The exception record contains a pointer to an exception handler block
-and an exception PMC (and possibly a continuation)
+Push an exception record somewhere, presumably on the exception handler
+stack. The exception record contains a pointer to an exception handler
+block, an exception PMC, and (optionally) a continuation.
=item 3
Invoke the handler (note: this is still in the thrower's dynamic
-context)
+context).
=back
-If the handler returns normally:
+If the handler returns without calling C<handled>:
=over
=item 1
-Find the "exception handling in progress" record
+Find the "exception handling in progress" record.
=item 2
-Find the next exception handler
+Find the next exception handler.
=item 3
-If the handler is found, invoke it
+If the handler is found, invoke it.
+
=item 4
-Or if there is a continuation in the exception record
-(because the throwing opcode was C<throwcc>),
-invoke the ER's continuation (i.e. resume execution)
+If no handler is found, and the exception is non-fatal (such as a
+warning), and there is a continuation in the exception record (because
+the throwing opcode was C<throwcc>), invoke the continuation (resume
+execution). Whether to resume or die when an exception isn't handled is
+determined by the severity of the exception.
=item 5
-Otherwise terminate program a la C<die>
+Otherwise terminate program a la C<die>.
=back
-{{ TODO: this isn't right, another option is a) invoke the handler, b)
-the handler calls handled, and c) invoke the continuation to resume
-because the exception was handled. The question of whether to resume or
-die when an exception is never handled is determined by the severity of
-the exception, not by the simple fact of having a continuation. }}
+When running an embedded Parrot interpreter, the interpreter does not
+immediately terminate on an unhandled exception, it merely returns
+control to the embedding program and stores the unhandled exception so
+that it may be queried by the embedding program. The embedding program
+may choose to handle the exception and continue execution by invoking
+the exception's continuation.
When the C<handled> opcode is called:
@@ -191,7 +191,11 @@
=over
=item 1
-Pop and destroy exception record
+Pop and destroy the exception record.
+
+=item 2
+If there was a continuation in the exception record, invoke the
+continuation.
=back
@@ -251,10 +255,6 @@
C<set_inner_exception()> method to store that previous exception
as part of the exception object.
-{{ TODO: Should we use properties instead? ANR: I'm not sure what you
-mean by "an exception is a consequence of a previous exception".
-Example? }}
-
=back
=head2 Standard Parrot Exceptions
@@ -285,8 +285,6 @@
=item B<exception;domain>
-{{ TODO: How about calling these B<exception;input>? }}
-
Generic base class for miscellaneous domain (input value) errors. Payload is
an array, the first element of which is the operation that failed (e.g. the
opcode name); subsequent elements depend on the value of the first element.
@@ -366,10 +364,23 @@
name requested doesn't exist in a lexical, current, global, or built-in
namespace.
-{{ FIXME - "errorson" as specified is dynamically rather than lexically
-scoped; is this good? ANR: There are a couple of different factors here.
-One is the ability to globally define the severity of certain exceptions
-or categories of exceptions without needing to define a handler for each
+{{ TODO: "errorson" as specified is dynamically rather than lexically
+scoped; is this good? Probably not good. Let's revisit it when we get
+the basic exceptions functionality implemented. }}
+
+It's a little odd that so few opcodes throw exceptions (these are the
+ones that are documented, but a few others throw exceptions internally
+even though they aren't documented as doing so). It's worth considering
+either expanding the use of exceptions consistently throughout the
+opcode set, or eliminating exceptions from the opcode set entirely. The
+strategy for error handling should be consistent, whatever it is. [I
+like the way C<LexPad>s and the C<errorson> settings provide the option
+for exception-based or non-exception-based implementations, rather than
+forcing one or the other.]
+
+{{ NOTE: There are a couple of different factors here. One is the
+ability to globally define the severity of certain exceptions or
+categories of exceptions without needing to define a handler for each
one. (e.g. Perl 6 may have pragmas to set how severe type-checking
errors are. A simple "incompatible type" error may be fatal under one
pragma, a resumable warning under another pragma, and completely silent
@@ -393,16 +404,6 @@
it still keeps the error information out-of-band, instead of mixing the
error in with normal return values. }}
-It's a little odd that so few opcodes throw exceptions (these are the
-ones that are documented, but a few others throw exceptions internally
-even though they aren't documented as doing so). It's worth considering
-either expanding the use of exceptions consistently throughout the
-opcode set, or eliminating exceptions from the opcode set entirely. The
-strategy for error handling should be consistent, whatever it is. [I
-like the way C<LexPad>s and the C<errorson> settings provide the option
-for exception-based or non-exception-based implementations, rather than
-forcing one or the other.]
-
=head2 Resuming after Exceptions
Exceptions thrown by standard Parrot opcodes (like the one thrown by
@@ -417,20 +418,6 @@
$P1 = new ['parrot';'exception'], $P0 # create new exception object
throw $P1 # throw it
-=head2 Consequenses
-
-Exceptions are designed to work with the Parrot calling conventions.
-Since the return addresses of C<bsr> subroutine calls and exception
-handlers are both pushed onto the control stack, it's generally a bad
-idea to combine the two.
-
-{{ TODO: If this continues to be true, then we need a way to turn off
-all exceptions. A number of built-in opcodes throw exceptions. If there
-is no way to prevent this, then it is never safe to use the control
-stack for anything other than exceptions. Alternatively, we leave the
-control stack safe for more primitive control flow, and pick another
-strategy for exceptions. }}
-
=head1 ATTACHMENTS
None.
Bob Rogers
Date: Sat, 8 Jul 2006 16:48:28 -0700 (PDT)
Author: allison
Date: Sat Jul 8 16:48:27 2006
New Revision: 13214
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
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:
=over
=item 1
Pop and destroy the exception record.
=item 2
If there was a continuation in the exception record, invoke the
continuation.
=back
According to C<throwcc>, this continution is for resuming execution from
the error point:
=item B<throwcc I<EXCEPTION> [ , I<CONTINUATION> ]>
Throw an exception consisting of the given I<EXCEPTION> PMC after taking
a continuation at the next opcode. When a I<CONTINUATION> is passed in,
it will use that instead. Active exception handlers (if any) will be
invoked with I<EXCEPTION> and the given continuation as parameters.
That would mean that C<handled> is really causing resumption, true? But
the C<handled> op description still merely says:
=item B<handled I<EXCEPTION>>
While handling an exception, tell Parrot that the exception has
been handled and should be removed from the stack of active
exceptions. This opcode is an exception handler's way of
telling Parrot that it has handled the exception.
It doesn't mention this possible nonlocal exit. It also doesn't mention
the fact that handlers that want to do something other than resuming
must *not* call C<handled> if they want to retain control, which seems
to contradict what Chip said on 24-June. On the other hand, not calling
C<handled> would leave the "exception record" in place, which also seems
wrong.
So I am confused. What is the intent here?
TIA,
-- Bob Rogers
http://rgrjr.dyndns.org/
Chip Salzenberg
> 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:
>
> 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 <ch...@pobox.com>