Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors

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