Front page | perl.perl6.language |
Postings from July 2006
[svn:perl6-synopsis] r9753 - doc/trunk/design/syn
From:
larry
Date:
July 3, 2006 12:01
Subject:
[svn:perl6-synopsis] r9753 - doc/trunk/design/syn
Message ID:
20060703190053.F3FF4CC276@x12.develooper.com
Author: larry
Date: Mon Jul 3 12:00:53 2006
New Revision: 9753
Modified:
doc/trunk/design/syn/S04.pod
Log:
Clarifications on stack unwinding semantics of exception handlers.
Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Mon Jul 3 12:00:53 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <larry@wall.org>
Date: 19 Aug 2004
- Last Modified: 30 June 2006
+ Last Modified: 3 July 2006
Number: 4
- Version: 25
+ Version: 26
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -77,7 +77,7 @@
If you've referred to C<$x> prior to the first declaration, and the compiler
tentatively bound it to C<$OUTER::x>, then it's an error to declare it, and
-the compiler is allowed to complain at that point. If such use can't
+the compiler is required to complain at that point. If such use can't
be detected because it is hidden in an eval, then it is erroneous, since
the C<eval()> compiler might bind to either C<$OUTER::x> or the subsequently
declared "C<my $x>".
@@ -118,6 +118,9 @@
to get the Perl 5 behavior.
+Note that temporizations that are undone upon scope exit must be
+prepared to be redone if a continuation within that scope is taken.
+
=head1 Statement-ending blocks
A line ending with a closing brace "C<}>", followed by nothing but
@@ -409,6 +412,17 @@
of the C<CATCH> block. Handled exceptions break out past this implicit
rethrow.)
+A C<CATCH> block sees the lexical scope in which it defined, but the
+dynamic scope in which it is called, that is, as if it were called
+from the dynamic location that threw the exception. That is, the
+stack is not unwound until some exception handler chooses to
+unwind it by "handling" the exception in question. So logically,
+if the C<CATCH> block throws its own exception, you would expect the
+C<CATCH> block to catch its own exception recursively forever. However,
+a C<CATCH> must not behave that way, so we say that a C<CATCH> block
+never attempts to handle any exception thrown within its own dynamic scope.
+(Otherwise the C<die> in the previous paragraph would never work.)
+
=head1 Control Exceptions
All abnormal control flow is, in the general case, handled by the
@@ -495,7 +509,9 @@
abstraction that the compiler is free to optimize away (along with the
associated continuation) when the compiler or runtime can determine
that the semantics would be preserved by merely printing out the
-error and going on.
+error and going on. Since all exception handlers run in the dynamic
+context of the throw, that reduces to simply returning from the C<warn>
+function most of the time.
=head1 The goto statement
-
[svn:perl6-synopsis] r9753 - doc/trunk/design/syn
by larry