I am willing to withdraw RFC 63 if the following parts are included
somewhere in RFC 88 in this or equivalent language:
"Note that C<try> is a keyword, not a function. This is solely so that
a C<;> is not needed at the end of the last block, since so many people
are bound to think it shouldn't be there and forget."
Reason: venerable Perl developers (who will be evaluating the RFC)
generally think of exception handling in terms of eval BLOCK, which
requires a trailing ;
"C<try>, C<catch>, and C<continue> blocks share the same lexical scope, in
the same way that C<while> and C<continue> currently do. This is so that
variables (e.g., filehandles) defined in the C<try> block can be operated
on in the other blocks."
Reason: the desire to be able to say
try { my $fh = open $file }
finally { close $fh if $fh }
"There is debate over whether C<try> should be C<eval> so as not to use
another keyword. Since it has different semantics (rethrows uncaught
exceptions), it should not be C<eval>; but if this happens, then surely
C<eval BLOCK> should be retired since it is so similar there would be
confusion over what to use for exception handling. And no-one would
get the semicolons right :-)"
Reason: having two methods of exception handling in Perl which could
interact with each other in potentially harmful or confusing ways would be
a bad thing.
"Note: Some people think that exceptions should not be rethrown
implicitly. It would be possible to provide a method in the base Exception
class which users could override to change this behavior; however, the
action-at-a-distance nature of this is unpopular."
Reason: acknowledging earlier feedback.
"Note that the implementation might make it possible for the user to
selectively or globally ignore exceptions, so that perl continues executing
the line after the C<throw>
statement, by overriding the C<throw> method in one or more classes. The
possibility of this happening is so repugnant to some that the
implementation should probably prohibit it."
Reason: acknowledging earlier discussions.
"Some people think that not only should this use C<eval> instead of C<try>, but
an C<else> instead of multiple C<catch> blocks. One advantage of their
approach is that you can use an expression for the exception you wish to
catch in a C<switch> block:
eval { ... }
else {
switch ($@) {
case ^_->isa('Exception::IO') { ... }
case ^_->my_method { ... }
}
Now in this case, the problem arises, how should the code implicitly
rethrow uncaught exceptions? Without having to look inside the C<switch>
statement to see what it did? Most of the proponents of this model think
that uncaught exceptions should not be implicitly rethrown; one suggests
that the programmer should C<undef $@> at the end of every successful
<case> block, so that perl rethrows any C<$@> still extant at the end of
the C<else>. From a minimalist point of view, this is a quite excellent
suggestion that should be considered if this RFC is evaluated as requiring
too many new keywords: our objection to it is that it requires the
programmer to insert C<undef $@> in every instance of by far the the most
common type of clause (as well as not implementing the rich semantics of
our daisy-chained finally clauses)."
Reason: acknowledging many messages from people who thought this should be
implemented with the new switch statement.
--
Peter Scott
Pacific Systems Design Technologies
