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
>In the following 'system calls' mean anything not in the core language
>calling an external service, be it a 'real' system call (such as
>accept(), fork(), mkdir()) or a 'library' call (such as print(),
>syswrite() getpwent()).
I think this would be spot on for Perl 5, but it doesn't sit well with the
other stuff we've been talking about so far for Perl 6. Of course, all of
our stuff could be rejected as bloated castles in the air, so I would not
discourage this RFC on those grounds; that aside:
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
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
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
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.
--
Peter Scott
Pacific Systems Design Technologies
