On Tue, Aug 22, 2000 at 11:07:44PM -0700, Peter Scott wrote:
> At 04:32 AM 8/23/00 +0000, Perl6 RFC Librarian wrote:
> >One Should Not Get Away With Ignoring System Call Errors
> > Mailing List: [EMAIL PROTECTED]
>
> I think this should be perl6-language-errors
I scoured the -errors but all I could see was fancy-schmanzy talk
about OOish exceptions, that's why I wrote the anti-OO section.
Unless we get OO faster than its own shadow, I want OO nowhere near
low-level system calls.
> What about system calls which do return values but signal errors some other
> way? Yes, the only example that comes to my mind instantly is one that
> hasn't happened yet but is proposed for Perl 6:
>
> my $fh = open 'file';
>
> where $fh is undef if open failed, but this is an entirely reasonable
> syntax. Clearly, checking the return value isn't any indication of error
> checking. Do we really want to kill backwards compatibility for something
"The first operation done on the return value of open() shall be defined()
or you shall regret your pitiful existence."? (a flag on the scalar coming
from open that makes any other op than defined() to die and defined() clears
the flag)
> that has this and other loopholes as already pointed out in the RFC?
>
> We have been discussing a modified Fatal.pm which would be a lot smarter
> about exceptions in builtins. See RFC 70. I'll be posting more shortly
I'll see it but see above my doubts.
> about using it to enable or disable classes of these exceptions. I would
> like to see RFC 140 framed in terms of this; perhaps it is would be better
> off suggesting that the default for some or all builtins should be
> exception mode rather than return-and-set-$! mode. Nevertheless, I
The whole $! concept (its semantics) is rather clunky in my opinion: a
variable whose value makes sense only immediately after the failure
Bleagh. I'd rather make it not exist (be undefined?) at all unless
there was a failure *and* bind it somehow tighter to the return value.
Yes, unfortunately this may mean exactly some sort of OOish approach:
In my $fh = open('blah') the $fh would hold the handle if open is
okay, but if the open failed $fh would be undef and $fh->error() would
be the error code...?
> understand the differences between this suggestion and the framer's
> intentions; I'm just putting out an idea.
>
> 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.
I don't think that's nice, either. I like the proposed new open() syntax.
>
> --
> Peter Scott
> Pacific Systems Design Technologies
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
