Peter Scott wrote:
>
> If we were prepared to mandate that all system calls should return
> a value indicating success or failure *and nothing else*, I would
> probably not object to RFC 140 as is, but I think that would be
> unnecessarily crippling on the language.
Agreed. If one wants to make *sure* that no-one ignores failure
returns from system calls, have a C<use fatal;> pragma that converts
error returns in system functions into raised exceptions. That way
they *will* *not* be ignored unless they encounter a matching catch
that does not itself raise an exception, that is, unless they are
(1) explicitly and (2) cleanly caught and handled/ignored.
This basically means that the public API to every built-in function
foo() is modified to add two new lines to the end of the subroutine,
like this (Perl pseudo-code used here, $FATAL_MODE is the current
state of use/no fatal):
sub foo
{
my $err_code = ... ; # original foo code goes here
return $err_code unless $FATAL_MODE && $error_code != $ok;
throw Error::Code "Couldn't foo.", code => $err_code;
}
I'm not proposing RFC 88 because I think I came up with something
clever. PL/I had "on <exception> do <block>" in when, the mid-
'70s? (I wrote one PL/I program ca. then, and I do vaguely rember
on exception.) I'm proposing RFC 88 because I think those guys came
up with something clever, because the LISP-based throw/catch model
is proven and relatively elegant, because we use the technique
throughout our code at work (because over the years we have it works
so well in practice for large systems), and because I therefore want
Perl to make it easier for me to use this technique. Without
impacting anyone who couldn't care less (which includes me too,
when I'm doing quick-and-dirty scripts).
This exception handling thingy has been a pet project of mine since
I started doing structured things with it in Scheme, almost ten
years ago. Over the years I've tried every approach we've talked
about here. Our early OO exception experiments were, shall we say,
interesting.
Based on these experiences, I've come to the conclusion that the
exception handling mechanism (1) is fundamentally procedural, (2)
should be completely explicit, and (3) should be relatively simple.
Why? Because exception handling is actually slightly trickier than
local flow control--not only are you reading down the page of code,
now you have to always be aware, in the back of your mind, that at
any time the next line might be on another page, or even in another
binder.
But that's ok because that's already the way it is (because ++$i can
generate an arithmetic exception). Making it easier to cope with
this in Perl 6, even if only intended for large or critical systems
use, does have the nasty side effect of bringing this latent non-
local flow-control reality into the limelight, which frightens some
people who suddenly realize that for years they *haven't* been
always been aware of this in the back for their mind. Now they are
wondering just how robust some of their code is ;-) Nevertheless,
that's no argument for doing a bad job of how "try" et al work.
Yours, &c, Tony Olekshy
