Peter Scott wrote, in RFC 63 (v2):
>
> This RFC is very similar to RFC 88, which has slightly different
> syntax and adds functionality for adding exceptions to a stack.
> While this author considers that to be going a bit too far (he's
> tried it before and found he never made use of anything under the
> top level of the stack), he wouldn't mind if RFC 88 got adopted
> instead. This RFC is attempting to stake out a more minimalist
> position.
The author of RFC 88 (that's me) agrees with you that it is going
a bit too far. In fact, we mainly use the exception stack to
generate those fancy tracebacks into server logs, not to catch
them per se. I'm planning to revise RFC 88 to pull out the default
stack handling, but to provide hooks to allow such a stack to be
maintained via use of a module. Then, it's available for the fancy
stuff, and the except => sub { } => catch { } syntax and/or the
catch { switch } syntax can be used to deal with those rare special
cases where one would want to examine the stack (if it's enhooked).
One problem I still see with RFC 63 is that there is no syntax for
doing a string match on the exception's stringification, as in the
RFC 88 syntax:
except "division by 0" => catch { }
except qr/div.* by 0/ => catch { }
That's why RFC 88 provides both this form and the "except isa"
form. (Note that I'm planning to revise RFC 88 to require the
form "except match => 'foo'" or "except match => qr/foo/" to
remove the difficult rule about the reserved lower-case stuff,
and to add forms like "except tag => 'ABC.1234'" and "except
severity => /^(Fail|Fatal)$/', depending on how RFC 96, A Base
Class for Exception Objects, pans out.)
I'm also planning to revise RFC 88 to take a listref of strings
or REs wherever it currently takes a single string or RE, as in
the "except match" and "except isa" forms. Thanks to everyone
who participated in the discussion on this matter.
> A C<continue> block is a Java C<finally> block; it gets executed
> after the C<try> block, after any C<catch> blocks, but before any
> uncaught exception is re-thrown. In this case we were inheriting
> syntax from Perl rather than another language.
> Some people think it should be even more minimal by using C<eval>
> instead of C<try>, and C<else> instead of multiple C<catch>
> blocks.
As I mentioned elsewhere, it seems to me that continue connotes some
sort of looping thing, not "whether or not unwinding". I'd much
rather take the hit of a new but traditional exception handling
keyword like "finally", than the hit of conceptually overloading
continue in this case. Minimalism only goes so far, in the sense
that even Bauhaus and wabi sabi tend to have doors that are not the
same as windows. And I'm no lexicographer, but I think finally
pre-dates Java.
There's another thing too. If we use finally instead of continue,
then we can continue to maintain a Perl 5 implementation. This
means that (1) we can continue to experiment with the implementation
and build regression tests before Perl 6 is born, and (2) Perl 5
programs and modules can begin to migrate to the new exception object
and exception handling mechanism while still running in Perl 5. The
value of these benefits may be greater than epsilon.
> A C<try> block without any C<catch> blocks would be pointless,
> since uncaught exceptions (i.e., all of them) would be rethrown.
Whoa. What about making sure that if a file is opened then it
is closed, even if the processing between open and close throws,
as in:
open(*F, ">foo") or throw ...;
try { ... }
finally { close F or throw ...; }
or making sure an object's clean-up routine is called, in cases
where the default GC doesn't do the job for you, as in:
my $o;
try { f ( $o = SomeClass->New ); }
finally { $o and $o->Done; }
> The C<exception> function is just syntactic sugar for creating
> a new exception class, it merely amounts to @EXCEPTION::ISA =
> 'Exception'.
That reminds me, I need to revise RFC 96 to add a throw constructor
and to allow some sort of construct like:
use Exception Class => "Database::Write";
> RFC 80 proposes standard exception classes and methods for
> core exceptions.
I also submitted RFC 96, which tries to address the stuff that
is needed for extending beyond builtins while maintaining a
standard Perl OO implementation and seperating the exception
handling stuff from the exception class. Rereading RFC 80, I
realize that they are closer than I thought, each emphasising
different aspects of the problem. No doubt we can eventually
merge these, as may become the case with 63 and 88 as well.
It's a pleasure to work with you on these matters. It appears
to me that Peter's approach in RFCs 63 and 80 represents the
perspective that the exception is the key and handling is just
what you do with it, whereas my approach in RFCs 88 and 96 is
that handling exceptions is the key, and the exceptions are just
what you happen to be handling.
We should be able to do a pretty good job of putting these two
perspectives together into binocular vision (-; | ;-)
Yours, &c, Tony Olekshy
