Peter Scott wrote:
>
> I am willing to withdraw RFC 63 if the following parts are
> included somewhere in RFC 88 in this or equivalent language:
I should like to note that I would like Peter to be described
as a co-author in RFC 88, whether or not RFC 63 is withdrawn.
That is, with his permission, of course. We can persue this
in non-list email, if you like.
I would also like to change the RFC title (can I do that) to:
"Structured Exception/Error Handling Mechanism"
> "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 ;
I've added this to DESCRIPTION + try:
Note that C<try> is a keyword, not a function. This is so
that a C<;> is not needed at the end of the last block.
This is because a try/catch/finally now looks more like an
if/elsif/else, which does not require such a C<;>, than like
an eval, which does).
> "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 }
It's in the queue.
> "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.
I think that that because of the different semantics, and in
order to allow people to continue to use classic examples of
classic Perl mechanisms, eval should stay in. And, of course,
we still need eval $string;
I have however queued the above for addition to ISSUES + eval.
If it goes though, we may need to add a mechanism for clearing
$@ and @@ (we currently rely on eval to do that).
> "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.
Actually, I am going to propose a $myException->handler method
that is invoked before an exception is raised so it can have a
go at handling the exception. If it throws or does not return
true the exception is raised, otherwise it is not.
This makes no sense for Error objects! But that's ok because
Exception's C<handler> method returns 0, and Error doesn't
override it (and, well, they could use handler for ivar munging
as long as they return true).
My motivation for this is that all the reference and text books
I've studied over the last few days say that classically, an
exception has such a handler hook. If we do provide it, it need
not be used, but if we don't provide it the functionality cannot
otherwise be provided, should it be deemed desireable for some
application.
> "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.
I've added this to the RFC queue, with explicit reference to the
proposed handler method.
> "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.
Excellent. It's in.
Yours, &c, Tony Olekshy
